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Computer-Aided Software Engineer¬ 
ing (CASE) is the widespread com¬ 
mercial application of software engi¬ 
neering techniques and computer 
technology to information systems 
development. 

The mission of CASE '90 is to 
exchange, synthesize, and dissemi¬ 
nate ideas among users, develop¬ 
ers, researchers, and supporters of 
CASE with the goal of advancing 
CASE technology and its effective 
use. The theme for CASE '90 is 
Cooperation 

Working groups will discuss the cur¬ 
rent state-of-the-art, research direc¬ 
tions, and future requirements in the 
following topic areas: 

■ Existing Systems 
-Maintenance & Management 
-Reverse Engineering & Design 

Recovery 

-Salvaging Software for Reuse 

■ Managing the Transitions 
-Use & Abuse of CASE 

- Technology Transfer 
-Methods & Tools to Support the 

Transitions 

- Transition from Research to 
Product 

■ Group & Process Management 
-Group Work Support Tools 

- Metrics /Measurements 
—Risk Analysis & Management 
-Quality 

■ Enabling Technologies 
-CASE Tool Integration 
-Repositories 
-MetaCASE 

■ Methods & Tools 
-Requirements Elicitation & 

Traceability 
-Software Reuse 
-Object Oriented Methods 
-Formal Methods 
-Verification & Validation Tools 

- The Effect of CASE on Software 
Engineering Practices 


CASE '90 is a limited attendance 
workshop primarily for those inter¬ 
ested in advancing the state-of-the- 
art of CASE. Prospective attendees 
must submit 6 copies of a one to 
two page position paper in English 
by April 30, 1990 

Position papers should relate to the 
cooperation of tools, people, meth¬ 
ods and software-and how they 
pertain to the state-of-the-art, 
research directions, and future 
requirements for CASE in one of the 
workshop topic areas. 

Paper submitters must include their 
name, address, daytime phone 
number, fax number if available, and 
the workshop topic area. Send 
papers to the closest regional coor¬ 
dinator. Papers from North America 
and areas not listed should be 
addressed to the Program Chair. 

The Program Committee will review 
papers and notify submitters of their 
acceptance to attend the workshop. 
Some attendees will be invited to 
discuss their papers to help focus 
the CASE '90 discussions. 

In addition, prospective attendees 
may submit longer papers (maxi¬ 
mum of 5000 words) dealing with 
any of the workshop topic areas. 
However, each author and co-author 
must submit a position paper to be 
considered for workshop atten¬ 
dance. 

CASE '90 and ACM's Sigsoft 90 
Software Development Environments 
symposium have been scheduled 
back-to-back in the same hotel to 
encourage cooperation between 
research and industrial facets of 
software engineering environment 
technology. 
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SURVEY & TUTORIAL SERIES 


A Survey of 
Parallel Computer 
Architectures 


Ralph Duncan, Control Data Corporation 



T his decade has witnessed the in¬ 
troduction of a wide variety of 
new computer architectures for 
parallel processing that complement and 
extend the major approaches to parallel 
computing developed in the 1960s and 
1970s. The recent proliferation of parallel 
processing technologies has included new 
parallel hardware architectures (systolic 
and hypercube), interconnection technolo¬ 
gies (multistage switching topologies), 
and programming paradigms (applicative 
programming). The sheer diversity of the 
field poses a substantial obstacle to the 
nonspecialist who wishes to comprehend 
what kinds of parallel architectures exist 
and how their relationship to one another 
defines an orderly schema. 

This discussion attempts to place recent 
architectural innovations in the broader 
context of parallel architecture develop¬ 
ment by surveying the fundamentals of 
both newer and more established parallel 
computer architectures and by placing 
these architectural alternatives in a coher¬ 
ent framework. The survey’s primary 
emphasis concerns architectural con¬ 
structs rather than specific parallel ma¬ 
chines. 

Terminology and 
taxonomy 

Problems. Diverse definitions have 
been proposed for parallel architectures. 
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The diversity of 
parallel computer 
architectures can 
bewilder the non¬ 
specialist. This tutorial 
reviews alternative 
approaches to parallel 
processing within the 
framework of a high- 
level taxonomy. 


The difficulty in precisely defining the 
term is intertwined with the problem of 
specifying a parallel architecture taxon¬ 
omy. A central problem for specifying a 
definition and consequent taxonomy for 
modem parallel architectures is to satisfy 
the following set of imperatives: 

• Exclude architectures incorporating 
only low-level parallel mechanisms 
that have become commonplace fea¬ 
tures of modern computers. 

• Maintain elements of Flynn’s useful 
taxonomy 1 based on instruction and 
data streams. . 
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• Include pipelined vector processors 
and other architectures that intuitively 
seem to merit inclusion as parallel 
architectures, but which are difficult to 
gracefully accommodate within 
Flynn’s scheme. 

We will examine each of these impera¬ 
tives as we seek a definition that satisfies 
all of them and provides the basis for a 
reasonable taxonomy. 

Low-level parallelism. There are two 
reasons to exclude machines that employ 
only low-level parallel mechanisms from 
the set of parallel architectures. First, fail¬ 
ure to adopt a more rigorous standard might 
make the majority of modem computers 
“parallel architectures,” negating the 
term’s usefulness. Second, architectures 
having only the features listed below do 
not offer an explicit, coherent framework 
for developing high-level parallel solu- 


Instruction pipelining — the decom¬ 
position of instruction execution into a 
linear series of autonomous stages, 
allowing each stage to simultaneously 
perform a portion of the execution 
process (such as decode, calculate ef¬ 
fective address, fetch operand, exe¬ 
cute, and store). 

Multiple CPU functional units — 
providing independent functional 
units for arithmetic and Boolean 
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Figure 1. High-level taxonomy of parallel computer architectures. 


operations that execute concurrently. 

• Separate CPU and HO processors — 
freeing the CPU from I/O control re¬ 
sponsibilities by using dedicated I/O 
processors; solutions range from rela¬ 
tively simple I/O controllers to com¬ 
plex peripheral processing units. 

Although these features contribute signifi¬ 
cantly to performance engineering, their 
presence does not make a computer a par¬ 
allel architecture. 

Flynn’s taxonomy. Flynn’s taxonomy 
classifies architectures on the presence of 
single or multiple streams of instructions 
and data. This yields the four categories 
below: 

SISD (single instruction, single data 
stream) — defines serial computers. 

MISD (multiple instruction, single data 
stream) — would involve multiple 
processors applying different instruc¬ 
tions to a single datum; this hypotheti¬ 
cal possibility is generally deemed 
impractical. 

S1MD (single instruction, multiple data 
streams) — involves multiple proces¬ 
sors simultaneously executing the 
same instruction on different data (this 
definition is discussed further prior to 
examining array processors below). 


MIMD (multiple instruction, multiple 
data streams) — involves multiple 
processors autonomously executing 
diverse instructions on diverse data. 

Although these distinctions provide a 
useful shorthand for characterizing archi¬ 
tectures, they are insufficient for classify¬ 
ing various modern computers. For ex¬ 
ample, pipelined vector processors merit 
inclusion as parallel architectures, since 
they exhibit substantial concurrent arith¬ 
metic execution and can manipulate hun¬ 
dreds of vector elements in parallel. How¬ 
ever, they are difficult to accommodate 
within Flynn’s taxonomy, because they 
lack processors executing the same in¬ 
struction in SIMD lockstep and lack the 
asynchronous autonomy of the MIMD 
category. 

Definition and taxonomy. A first step 
to providing a satisfactory taxonomy is to 
articulate a definition of parallel architec¬ 
ture. The definition should include appro¬ 
priate computers that the Flynn schema 
cannot handle and exclude architectures 
incorporating only low-level parallelism. 
Therefore, a parallel architecture provides 
an explicit, high-level framework for the 
development of parallel programming so¬ 
lutions by providing multiple processors, 
whether simple or complex, that cooperate 


to solve problems through concurrent 
execution. 

Figure 1 shows a taxonomy based on the 
imperatives discussed earlier and the pro¬ 
posed definition. This informal taxonomy 
uses high-level categories to delineate the 
principal approaches to parallel computer 
architectures and to show that these ap¬ 
proaches define a coherent spectrum of 
architectural alternatives. Definitions for 
each category are provided below. 

This taxonomy is not intended to sup¬ 
plant efforts to construct more fully articu¬ 
lated taxonomies. Such taxonomies pro¬ 
vide comprehensive subcategories to re¬ 
flect permutations of architectural charac¬ 
teristics and to cover lower level features. 
The “Further reading” section at the end 
references several thoughtful taxonomic 
studies that address these goals. 

Synchronous 

architectures 

Synchronous parallel architectures co¬ 
ordinate concurrent operations in lockstep 
through global clocks, central control 
units, or vector unit controllers. 

Pipelined vector processors. The first 
vector processor architectures were devel¬ 
oped in the late 1960s and early 1970s 2,3 to 
directly support massive vector and matrix 
calculations. Vector processors 4 are char¬ 
acterized by multiple, pipelined functional 
units, which implement arithmetic and 
Boolean operations for both vectors and 
scalars and which can operate concur¬ 
rently. Such architectures provide parallel 
vector processing by sequentially stream¬ 
ing vector elements through a functional 
unit pipeline and by streaming the output 
results of one unit into the pipeline of 
another as input (a process known as 
“chaining”). 

A representative architecture might 
have a vector addition unit consisting of 
six pipeline stages (see Figure 2). If each 
pipeline stage in the hypothetical architec¬ 
ture shown in the figure has a cycle time of 
20 nanoseconds, then 120 ns elapse from 
the time operands a\ and b 1 enter stage 1 
until result cl is available. When the pipe¬ 
line is filled, however, a result is available 
every 20 ns. Thus, start-up overhead of 
pipelined vector units has significant per¬ 
formance implications. In the case of the 
register-to-register architecture depicted, 
special high-speed vector registers hold 
operands and results. Efficient perform¬ 
ance for such architectures (for example, 
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the Cray-1 and Fujitsu VP-200) is obtained 
when vector operand lengths are multiples 
of the vector register size. Memory-to- 
memory architectures (such as the Control 
Data Cyber 205 and Texas Instruments 
Advanced Scientific Computer) use spe¬ 
cial memory buffers instead of vector 
registers. 

Recent vector processing supercomput¬ 
ers (such as the Cray X-MP/4 and ETA-10) 
unite four to 10 vector processors through 
a large shared memory. Since such archi¬ 
tectures can support task-level parallel¬ 
ism, they could arguably be termed MIMD 
architectures, although vector processing 
capabilities are the fundamental aspect of 
their design. 

SIMD architectures. SIMD architec¬ 
tures (see Figure 3) typically employ a 
central control unit, multiple processors, 
and an interconnection network (IN) for 
either processor-to-processor or proces- 
sor-to-memory communications. The con¬ 
trol unit broadcasts a single instruction to 
all processors, which execute the instruc¬ 
tion in lockstep fashion on local data. The 
interconnection network allows instruc¬ 
tion results calculated at one processor to 
be communicated to another processor for 
use as operands in a subsequent instruc¬ 
tion. Individual processors may be allowed 
to disable the current instruction. 

Processor array architectures. Proces¬ 
sor arrays 5 structured for numerical SIMD 
execution have often been employed for 
large-scale scientific calculations, such as 
image processing and nuclear energy 
modeling. Processor arrays developed in 
the late 1960s (such as the Illiac-IV) and 
more recent successors (such as the Bur¬ 
roughs Scientific Processor) utilize proc¬ 
essors that accommodate word-sized oper¬ 
ands. Operands are usually floating-point 
(or complex) values and typically range in 
size from 32 to 64 bits. Various IN schemes 
have been used to provide processor-to- 
processor or processor-to-memory com¬ 
munications, with mesh and crossbar ap¬ 
proaches being among the most popular. 

One variant of processor array architec¬ 
tures involves using a large number of one- 
bit processors. In bit-plane architectures, 
the array of processors is arranged in a 
symmetrical grid (such as 64x64) and as¬ 
sociated with multiple “planes” of mem¬ 
ory bits that correspond to the dimensions 
of the processor grid (see Figure 4). 
Processor n (P n ), situated in the processor 
grid at location (x, y), operates on the 
memory bits at location (x, y) in all the 


Vector 
register A 



Figure 2. Register-to-register vector architecture operation. 



Figure 3. SIMD execution. 



Figure 4. Bit-plane array processing. 
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Figure 5. Associative memory processing organization. 


associated memory planes. Usually, op¬ 
erations are provided to copy, mask, and 
perform arithmetic operations on entire 
memory planes, as well as on columns and 
rows within a plane. 

Loral’s Massively Parallel Processor 6 
and ICL’s Distributed Array Processor 
exemplify this kind of architecture, which 
is often used for image processing applica¬ 
tions by mapping pixels to the memory’s 
planar structure. Thinking Machines’ 
Connection Machine organizes as many as 
65,536 one-bit processors as sets of four- 
processor meshes united in a hypercube 
topology. 

Associative memory processor architec¬ 
tures. Computers built around an associa¬ 
tive memory 7 constitute a distinctive type 
of SIMD architecture that uses special 
comparison logic to access stored data in 


parallel according to its contents. Research 
in constructing associative memories be¬ 
gan in the late 1950s with the obvious goal 
of being able to search memory in parallel 
for data that matched some specified da¬ 
tum. “Modem” associative memory proc¬ 
essors developed in the early 1970s (for 
example. Bell Laboratories’ Parallel Ele¬ 
ment Processing Ensemble, or PEPE) and 
recent architectures (for example, Loral’s 
Associative Processor, or Aspro) have 
naturally been geared to database-oriented 
applications, such as tracking and surveil¬ 
lance. 

Figure 5 shows the characteristic func¬ 
tional units of an associative memory pro¬ 
cessor. A program controller (serial com¬ 
puter) reads and executes instructions, 
invoking a specialized array controller 
when associative memory instructions are 
encountered. Special registers enable the 


program controller and associative mem¬ 
ory to share data. 

Most current associative memory pro¬ 
cessors use a bit-serial organization, which 
involves concurrent operations on a single 
bit-slice (bit-column) of all the words in 
the associative memory. Each associative 
memory word, which usually has a very 
large number of bits (for example, 32,768), 
is associated with special registers and 
comparison logic that functionally consti¬ 
tute a processor. Hence, an associative 
processor with 4,096 words effectively has 
4,096 processing elements. 

Figure 6 depicts a row-oriented com¬ 
parison operation for a generic bit-serial 
architecture. A portion of the comparison 
register contains the value to be matched. 
All of the associative processing elements 
start at a specified memory column and 
compare the contents of four consecutive 
bits in their row against the comparison 
register contents, setting a bit in the A 
register to indicate whether or not their row 
contains a match. 

In Figure 7 a logical OR operation is 
performed on a bit-column and the bit- 
vector in register A, with register B receiv¬ 
ing the results. A zero in the mask register 
indicates that the associated word is not to 
be included in the current operation. 

Systolic architectures. In the early 
1980s H.T. Kung of Carnegie Mellon 
University proposed systolic architectures 
to solve the problems of special-purpose 
systems that must often balance intensive 
computations with demanding I/O 
bandwidths. 8 Systolic architectures (sys¬ 
tolic arrays) are pipelined multiprocessors 
in which data is pulsed in rhythmic fashion 
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Figure 6. Associative memory comparison operation. 
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Figure 7. Associative memory logical OR operation. 
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Figure 8. Systolic flow of data from 
and to memory. 


from memory and through a network of 
processors before returning to memory 
(see Figure 8). A global clock and explicit 
timing delays synchronize this pipelined 
data flow, which consists of operands ob¬ 
tained from memory and partial results to 
be used by each processor. Modular pro¬ 
cessors united by regular, local intercon¬ 
nections provide basic building blocks for 
a variety of special-purpose systems. Dur¬ 
ing each time interval, these processors 
execute a short, invariant sequence of in¬ 
structions. 

Systolic arrays address the performance 
requirements of special-purpose systems 
by achieving significant parallel computa¬ 
tion and by avoiding I/O and memory 
bandwidth bottlenecks. A high degree of 
parallelism is obtained by pipelining data 
through multiple processors, typically in 
two-dimensional fashion. Systolic archi¬ 
tectures maximize the computations per¬ 
formed on a datum once it has been ob¬ 
tained from memory or an external device. 
Hence, once a datum enters the systolic 
array, it is passed to any processor that 
needs it, without an intervening store to 
memory. Only processors at the topologi¬ 
cal boundaries of the array perform I/O to 
and from memory. 

Figure 9a-e shows how a simple systolic 
array could calculate the outer product of 
two matrices, 

A = I a b I and B = I e f I 
I c d I I g hi 

The zero inputs shown moving through the 
array are used for synchronization. Each 
processor begins with an accumulator set 
to zero and, during each cycle, adds the 
product of its two inputs to the accumula¬ 
tor. After five cycles the matrix product is 
complete. 

A growing number of special-purpose 
systems use systolic organization for algo¬ 
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Figure 9. Systolic matrix multipli¬ 
cation. 


rithm-specific architectures, particularly 
for signal processing. In addition, pro¬ 
grammable (reconfigurable) systolic 
architectures (such as Carnegie Mellon’s 
Warp and Saxpy’s Matrix-1) have been 
constructed that are not limited to imple¬ 
menting a single algorithm. Although sys¬ 
tolic concepts were originally proposed for 
VLSI-based systems to be implemented at 
the chip level, systolic architectures have 
been implemented at a variety of physical 
levels. 

MIMD architectures 

MIMD architectures employ multiple 


processors that can execute independent 
instruction streams, using local data. Thus, 
MIMD computers support parallel solu¬ 
tions that require processors to operate in a 
largely autonomous manner. Although 
software processes executing on MIMD 
architectures are synchronized by passing 
messages through an interconnection net¬ 
work or by accessing data in shared mem¬ 
ory units, MIMD architectures are asyn¬ 
chronous computers, characterized by 
decentralized hardware control. 

The impetus for developing MIMD 
architectures can be ascribed to several 
interrelated factors. MIMD computers 
support higher level parallelism (subpro¬ 
gram and task levels) that can be exploited 
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Figure 10. MIMD distributed memory 
architecture structure. 


by “divide and conquer” algorithms organ¬ 
ized as largely independent subcalcula¬ 
tions (for example, searching and sorting). 
MIMD architectures may provide an alter¬ 
native to depending on further implemen¬ 
tation refinements in pipelined vector 
computers to provide the significant per¬ 
formance increases needed to make some 
scientific applications tractable (such as 
three-dimensional fluid modeling). Fi¬ 
nally, the cost-effectiveness of n-proces- 
sor systems over n single-processor sys¬ 
tems encourages MIMD experimentation. 

Distributed memory architectures. 

Distributed memory architectures (Figure 
10) connect processing nodes (consisting 
of an autonomous processor and its local 
memory) with a processor-to-processor 



Figure 11. MIMD interconnection network topologies: (a) ring; (b) mesh; 
(c) tree; (d) hypercube; (e) tree mapped to a reconfigurable mesh. 


interconnection network. Nodes share data 
by explicitly passing messages through the 
interconnection network, since there is no 
shared memory. A product of 1980s re¬ 
search, these architectures have princi¬ 
pally been constructed in an effort to pro¬ 
vide a multiprocessor architecture that will 
“scale” (accommodate a significant in¬ 
crease in processors) and will satisfy the 
performance requirements of large scien¬ 
tific applications characterized by local 
data references. 

Various interconnection network to¬ 
pologies have been proposed to support 
architectural expandability and provide 
efficient performance for parallel pro¬ 
grams with differing interprocessor com¬ 
munication patterns. Figure lla-e depicts 
the topologies discussed below. 

Ring topology architectures. The com¬ 
munication diameter ( N/2) of ring topol¬ 
ogy architectures can be reduced by adding 
chordal connections. Using chordal con¬ 
nections or multiple rings can increase a 
ring-based architecture’s fault tolerance. 
Typically, fixed-size message packets are 
used that include a node destination field. 
Ring topologies are most appropriate for 
a small number of processors executing 
algorithms not dominated by data com¬ 
munications. 

Mesh topology architectures. A two- 
dimensional mesh, or lattice, topology has 
n 2 nodes, each connected to its four imme¬ 
diate neighbors. Wraparound connections 
at the edges are sometimes provided to 
reduce the communication diameter from 
2(n-l) to 2 * (Integer-part of n/2). Com¬ 
munications may be augmented by provid¬ 
ing additional diagonal links or by using 
buses to connect nodes by rows and col¬ 
umns. The topological correspondence 
between meshes and matrix-oriented algo¬ 
rithms encourages mesh-based architec¬ 
ture research. 

Tree topology architectures. Tree topol¬ 
ogy architectures, such as Columbia Uni¬ 
versity’s DAD02 and Non-Von, have been 
constructed to support divide-and-conquer 
algorithms for searching and sorting, im¬ 
age processing algorithms, and dataflow 
and reduction programming paradigms. 
Although a variety of tree-structured to¬ 
pologies have been suggested, complete 
binary trees are the most analyzed variant. 

Several strategies have been employed 
to reduce the communication diameter of 
tree topologies (2(zi—1) for a complete 
binary tree with n levels and 2”-l pro- 
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cessors). Example solutions include add¬ 
ing additional interconnection network 
pathways to unite all nodes at the same 
tree level. 

Hypercube topology architectures. A 
Boolean n-cube or “hypercube” topology 
uses N = 2" processors arranged in an n- 
dimensional cube, where each node has 
«=log 2 (V bidirectional links to adjacent 
nodes. Individual nodes are uniquely iden¬ 
tified by n-bit numeric values ranging from 
0 to N- 1 and assigned in a manner that 
ensures adjacent nodes’ values differ by a 
single bit. The communication diameter of 
such a hypercube topology architecture is 
n=log 2 A. 

Hypercube architecture research has 
been strongly influenced by the desire to 
develop a “scalable” architecture that sup¬ 
ports the performance requirements of 3D 
scientific applications. Extant hypercube 
architectures include the Cosmic Cube, 
Ametek Series 2010, Intel Personal Super¬ 
computer, and Ncube/10. 

Reconfigurable topology architectures. 
Although distributed memory architec¬ 
tures possess an underlying physical topol¬ 
ogy, reconfigurable topology architectures 
provide programmable switches that allow 
users to select a logical topology matching 
application communication patterns. The 
functional reconfigurability available in 
research prototypes ranges from specify¬ 
ing different topologies (such as Lawrence 
Snyder’s Configurable Highly Parallel 
Computer, or Chip) to partitioning a base 
topology into multiple interconnection 
topologies of the same type (such as 
Howard J. Siegel’s Partitionable SIMD/ 
MIMD System, or Pasm). A significant 
motivation for constructing reconfigurable 
topology architectures is that a single 
architecture can act as many special-pur¬ 
pose architectures that efficiently support 
the communications patterns of particular 
algorithms or algorithm steps. 

Shared-memory architectures. 

Shared memory architectures accomplish 
interprocessor coordination by providing a 
global, shared memory that each processor 
can address. Commercial shared-memory 
architectures, such as Flexible Corpora¬ 
tion’s Flex/32 and Encore Computer’s 
Multimax, were introduced during the 
1980s. These architectures involve mul¬ 
tiple general-purpose processors sharing 
memory, rather than a CPU and peripheral 
I/O processors. Shared memory computers 
do not have some of the problems encoun¬ 


tered by message-passing architectures, 
such as message sending latency as data is 
queued and forwarded by intermediate 
nodes. However, other problems, such as 
data access synchronization and cache 
coherency, must be solved. 

Coordinating processors with shared 
variables requires atomic synchronizing 
mechanisms to prevent one process from 
accessing a datum before another finishes 
updating it. These mechanisms provide an 
atomic operation that subjects a “key” to a 
comparison test before allowing either the 
key or associated data to be updated. The 
“test-and-set” mechanism, for example, is 
an atomic operation for testing the key’s 
value and, if the test result is true, updating 
the key value. 

Typically, each processor in a shared 


memory architecture also has a local 
memory used as a cache. Multiple copies 
of the same shared memory data, therefore, 
may exist in various processors’ caches at 
a given time. Maintaining a consistent 
version of such data is the cache coherency 
problem, which concerns providing new 
versions of the cached data to each in¬ 
volved processor whenever a processor 
updates its copy. Although systems with a 
small number of processors can use hard¬ 
ware “snooping” mechanisms to determine 
when shared memory data has been up¬ 
dated, larger systems usually rely on soft¬ 
ware solutions to minimize performance 
impact. 

Figure 12a-c illustrates some major al¬ 
ternatives for connecting multiple proces¬ 
sors to shared memory (outlined below). 




(c) 


Figure 12. MIMD shared-memory interconnection schemes: (a) bus interconnec¬ 
tion; (b) 2x2 crossbar; (c) 8x8 omega MIN routing a P 3 request to M 3 . 
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Bus interconnections. Time-shared 
buses (Figure 12a) offer a fairly simple 
way to give multiple processors access to a 
shared memory. A single, time-shared bus 
effectively accommodates a moderate 
number of processors (from four to 20), 
since only one processor accesses the bus 
at a given time. Some bus-based architec¬ 
tures, such as the experimental Cm* archi¬ 
tecture, employ two kinds of buses — a 
local bus linking a cluster of processors 
and a higher level system bus linking dedi¬ 
cated service processors associated with 
each cluster. 

Crossbar interconnections. Crossbar 
interconnection technology uses a cross¬ 
bar switch of n 2 crosspoints to connect n 
processors to n memories (see Figure 12b). 
Processors may contend for access to a 
memory location, but crossbars prevent 
contention for communication links by 
providing a dedicated pathway between 
each possible processor/memory pairing. 

Power, pinout, and size considerations 
have limited crossbar architectures to a 
small number of processors (from four to 
16). The Alliant FX/8 is a commercial 
architecture that uses a crossbar scheme to 
connect processors and cache memories. 

Multistage interconnection networks. 
Multistage interconnection networks 
(MINs) 9 strike a compromise between the 
price/performance alternatives offered by 
crossbars and buses. An AxA MIN 


connects A processors to A memories by 
deploying multiple “stages” or banks of 
switches in the interconnection network 
pathway. 

When A is a power of 2, one approach is 
to employ log 2 A stages of A/2 switches, 
using 2x2 switches. A processor making a 
memory access request specifies the de¬ 
sired destination (and pathway) by issuing 
a bit-value that contains a control bit for 
each stage. The switch at stage i examines 
the ;'th bit to determine whether the input 
(request) is to be connected to the upper or 
lower output. 

Figure 12c shows an omega network 
connecting eight processors and memo¬ 
ries, where a control bit equal to zero in 
dicates a connection to the upper output. 
Expandability is a significant feature of 
such a MIN, since its communication 
diameter is proportional to log 2 A. The 
BBN (Bolt, Beranek, and Newman) But¬ 
terfly, for example, can be configured 
with as many as 256 processors. 

MIMD-based 

architectural 

paradigms 

MIMD/SIMD hybrids, dataflow archi¬ 
tectures, reduction machines, and 
wavefront arrays all pose a similar diffi¬ 
culty for an orderly taxonomy of parallel 
architectures. Each of these architectural 


types is predicated on MIMD principles of 
asynchronous operation and concurrent 
manipulation of multiple instruction and 
data streams. However, each of these ar¬ 
chitectures is also based on a distinctive 
organizing principle as fundamental to 
its overall design as MIMD characteris¬ 
tics. These architectures, therefore, are 
described under the category “MIMD- 
based architectural paradigms” to high¬ 
light their distinctive foundations as 
well as the MIMD characteristics they 
have in common. 

MIMD/SIMD architectures. A variety 
of experimental hybrid architectures con¬ 
structed during the 1980s allow selected 
portions of a MIMD architecture to be 
controlled in SIMD fashion (for example, 
DADO, Non-Von, Pasm, and Texas Re- 
configurable Array Computer, or 
TRAC). 14 The implementation mecha¬ 
nisms explored for reconfiguring architec¬ 
tures and controlling SIMD execution are 
quite diverse. Using a tree-structured, 
message-passing computer 10 as the base 
architecture for a MIMD/SIMD architec¬ 
ture helps illustrate the general concept. 

The master/slaves relation of a SIMD 
architecture’s controller and processors 
can be mapped onto the node/descendents 
relation of a subtree (see Figure 13). When 
the root processor node of a subtree oper¬ 
ates as a SIMD controller, it transmits 
instructions to descendent nodes that exe¬ 
cute the instructions on local memory data. 

The flexibility of MIMD/SIMD archi¬ 
tectures obviously makes them attractive 
candidates for further research. Specific 
incentives for recent development efforts 
include supporting parallel image process¬ 
ing and expert system applications. 

Dataflow architectures. The funda¬ 
mental feature of dataflow architectures is 
an execution paradigm in which instruc¬ 
tions are enabled for execution as soon as 
all of their operands become available. 
Thus, the sequence of executed instruc¬ 
tions is based on data dependencies, allow¬ 
ing dataflow architectures to exploit con¬ 
currency at the task, routine, and instruc¬ 
tion levels. A major incentive for dataflow 
architecture research, which dates from 
J.B. Dennis’ pioneering work in the mid- 
1970s, is to explore new computational 
models and languages that can be effec¬ 
tively exploited to achieve large-scale 
parallelism. 

Dataflow architectures execute data¬ 
flow graphs, such as the program fragment 
depicted in Figure 14. We can think of 


12 


COMPUTER 









Figure 14. Dataflow graph—program 
fragment. 


graph nodes as representing asynchronous 
tasks, although they are often single 
instructions. Graph arcs represent com¬ 
munications paths that carry execution 
results needed as operands in subsequent 
instructions. 

Some of the diverse mechanisms used to 
implement dataflow computers (such as 
the Manchester Data Flow Computer, MIT 
Tagged Token Data Flow architecture, and 
Toulouse LAU System) 11 are outlined be¬ 
low. Static implementations load all graph 
nodes into memory during initialization 
and allow only one instance of a node to be 
executed at a time; dynamic architectures 
allow the creation of node instances at 
runtime and multiple instances of a node to 
be executed concurrently. 

Some architectures directly store 
“tokens” containing instruction results in¬ 
to a template for the instruction that will 
use them as operands. Other architectures 
use token-matching schemes, in which a 
matching unit stores tokens and tries to 
match them with instructions. When a 
complete set of tokens (all required op¬ 
erands) is assembled for an instruction, 
an instruction template containing the 
relevant operands is created and queued 
for execution. 

Figure 15 shows how a simplified token¬ 
matching architecture might process the 
program fragment shown in Figure 14. At 
step 1, the execution of (3*a) results in the 
creation of a token that contains the result 
(15) and an indication that the instruction 
at node 3 requires this as an operand. Step 
2 shows the matching unit that will match 
this token and the result token of (5 *b) with 
the node 3 instruction. The matching unit 
creates the instruction token (template) 


shown at step 3. At step 4, the node store 
unit obtains the relevant instruction op¬ 
code from memory. The node store unit 
then fills in the relevant token fields (step 
5), and assigns the instruction to a proces¬ 
sor. The execution of the instruction will 
create a new result token to be used as 
input to the node 4 instruction. 

Reduction architectures. Reduction, 
or demand-driven, architectures 12 imple¬ 
ment an execution paradigm in which an 
instruction is enabled tor execution when 
its results are required as operands for 
another instruction already enabled for 
execution. Most reduction architecture 
research began in the late 1970s to explore 
new parallel execution paradigms and to 
provide architectural support for applica¬ 
tive (functional) programming languages. 

Reduction architectures execute pro¬ 
grams that consist of nested expressions. 
Expressions are recursively defined as lit¬ 
erals or function applications on argu¬ 
ments that may be literals or expressions. 


Programs may “reference” named expres¬ 
sions, which always return the same value 
(the referential transparency property). 
Reduction programs are function applica¬ 
tions constructed from primitive functions. 

Reduction program execution consists 
of recognizing reducible expressions, then 
replacing them with their calculated val¬ 
ues. Thus, an entire reduction program is 
ultimately reduced to its result. Since the 
general execution paradigm only enables 
an instruction for execution when its re¬ 
sults are needed by a previously enabled 
instruction, some additional rule is needed 
to enable the first instruction(s) and begin 
computation. 

Practical challenges for implementing 
reduction architectures include synchro¬ 
nizing demands for an instruction’s results 
(since preserving referential transparency 
requires calculating an expression’s re¬ 
sults once only) and maintaining copies of 
expression evaluation results (since an 
expression result could be referenced 
more than once but could be consumed 
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Figure 16. Reduction architecture demand token production. 


Figure 17. Reduction architecture result token production. 


by subsequent reductions upon first being 
delivered). 

Reduction architectures employ either 
string reduction or graph reduction to 
implement demand-driven paradigms. 
String reduction involves manipulating 
literals and copies of values, which are 
represented as strings that can be dynam¬ 
ically expanded and contracted. Graph 
reduction involves manipulating literals 
and references (pointers) to values. Thus, 
a program is represented as a graph, and 
garbage collection reclaims dynamically 
allocated memory as the reduction 
proceeds. 

Figures 16 and 17 show a simplified 
version of a graph-reduction architecture 
that maps the program below onto tree- 
structured processors and passes tokens 
that demand or return results. Figure 16 
depicts all the demand tokens produced 
by the program, as demands for the values 
of references propagate down the tree. In 
Figure 17, the last two result tokens 
produced are shown as they are passed to 
the root node. 


a = + b c; 

b = + d e; 

c = * f g; 

d= 1; e = 3; f = 5; g = 7. 

Rather dissimilar architectures (such as 
the Newcastle Reduction Machine, North 
Carolina Cellular Tree Machine, and Utah 
Applicative Multiprocessing System) 
have been proposed to support both string- 
and graph-reduction approaches. 

Wavefront array architectures. 

Wavefront array processors' 3 combine 
systolic data pipelining with an asynchro¬ 
nous dataflow execution paradigm. S-Y. 
Rung developed wavefront array concepts 
in the early 1980s to address the same kind 
of problems that stimulated systolic array 
research — producing efficient, cost-ef¬ 
fective architectures for special-purpose 
systems that balance intensive computa¬ 
tions with high I/O bandwidth (see the 
systolic array section above). 

Wavefront and systolic architectures are 
both characterized by modular processors 


and regular, local interconnection net¬ 
works. However, wavefront arrays replace 
the global clock and explicit time delays 
used for synchronizing systolic data pipe¬ 
lining with asynchronous handshaking as 
the mechanism for coordinating inter¬ 
processor data movement. Thus, when a 
processor has performed its computations 
and is ready to pass data to its successor, it 
informs the successor, sends data when the 
successor indicates it is ready, and receives 
an acknowledgment from the successor. 
The handshaking mechanism makes com¬ 
putational wavefronts pass smoothly 
through the array without intersecting, as 
the array’s processors act as a wave propa¬ 
gating medium. In this manner, correct 
sequencing of computations replaces the 
correct timing of systolic architectures. 

Figure 18a-c depicts wavefront array 
concepts, using the matrix multiplication 
example used earlier to illustrate systolic 
operation (Figure 9). The example archi¬ 
tecture consists of processing elements 
(PEs) that have a one-operand buffer for 
each input source. Whenever the buffer for 
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a memory input source is empty and the 
associated memory contains another oper¬ 
and, that available operand is immediately 
read. Operands from other PEs are ob¬ 
tained using a handshaking protocol. 

Figure 18a shows the situation after 
memory input buffers are initially filled. In 
Figure 18b PE( 1,1) adds the product ae to 
its accumulator and transmits operands a 
and e to neighbors; thus, the first computa¬ 
tional wavefront is shown propagating 
from PE( 1,1) to PE(1,2) and PE(2,1). Fig¬ 
ure 18c shows the first computational 
wavefront continuing to propagate, while a 
second wavefront is propagated by 
PE(1,1). 

Kung argued 13 that wavefront arrays 
enjoy several advantages over systolic 
arrays, including greater scalability, sim¬ 
pler programming, and greater fault toler¬ 
ance. Wavefront arrays constructed at 
Johns Hopkins University and at the Stan¬ 
dard Telecommunications Company and 
Royal Signals and Radar Establishment (in 
the United Kingdom) should facilitate 
further assessment of wavefront arrays’ 
proposed advantages. 


T he diversity of recently intro¬ 
duced parallel computer architec¬ 
tures confronts the interested 
observer with what R.W. Hockney has 
felicitously termed “a confusing menag¬ 
erie of computer designs.” 

This discussion has tried to address the 
difficulty of understanding these diverse 
parallel architecture designs. An underly¬ 
ing goal was to explain how the principal 
types of parallel architectures work. The 
informal taxonomy of parallel architecture 
types proposed here is meant to show that 
the parallel architectures reviewed define a 
coherent spectrum of architectural alterna¬ 
tives. The discussion shows that parallel 
architectures embody fundamental organ¬ 
izing principles for concurrent execution, 
rather than disparate collections of hard¬ 
ware and software features.® 


Acknowledgments 

Particular thanks are due Lawrence Snyder 
and the referees for constructive comments. 
Thanks go to the following individuals for 
providing research materials, descriptions of 
parallel architectures, and insights: Theodore 
Bashkow, Laxmi Bhuyan, Jack Dongarra, Paul 
Edmonds, Scott Fahlman, Dennis Gannon, E. 
Allen Garrard, H.T. Kung, G.J. Lipovski, David 
Lugowski, Miroslaw Malek, Robert Masson, 



Figure 18. Wavefront array matrix multiplication. 


February 1990 

























































































































































Susan Miller, James Peitrocini, Malcolm Rim- 
mer, Howard J. Siegel, Charles Seitz, Vason 
Srini, Salvatore Stolfo, David Waltz, and Jon 
Webb. 

This research was supported by the Rome Air 
Development Center under contract F30602- 
87-D-0092. 


Further reading 

J.J. Dongarra, ed., Experimental Parallel 
Computing Architectures, North-Holland, 
Amsterdam, 1987. 

R.W. Hockney, “Classification and Evaluation 
of Parallel Computer Systems,” in Springer- 
Verlag Lecture Notes in Computer Science, No. 
295, 1987, pp. 13-25. 

D.J. Kuck, “High-speed Machines and Their 
Compilers,” in Parallel Processing Systems, D. 
Evans, ed., Cambridge Univ. Press, 1982. 

J. Schwartz, “A Taxonomic Table of Parallel 
Computers, Based on 55 Designs,” Courant 
Institute, NYU, New York, Nov. 1983. 

D.B. Skillicorn, “A Taxonomy for Computer 
Architectures,” Computer, Vol. 21, No. 11, 
Nov. 1988, pp. 46-57. 


L. Snyder, “A Taxonomy of Synchronous Paral¬ 
lel Machines,” Proc. 17th Int’l Conf. Parallel 
Processing, University Park, Penn., August, 
1988. 


References 


1. M.J. Flynn, “Very High Speed Computing 
Systems,” Proc. IEEE, Voi. 54, 1966, pp. 
1901-1909. 

2. W.J. Watson, “The ASC — A Highly 
Modular Flexible Super Computer 
Architecture,” Proc. AFIPS FJCC, 1972, 

pp. 221-228. 

3. N.R. Lincoln, “A Safari through the Con¬ 
trol Data Star-100 with Gun and Camera,” 
Proc. AFIPS NCC, June 1978. 

4. K. Hwang, ed., Tutorial Supercomputers: 
Design and Applications, Computer Soci¬ 
ety Press, Los Alamitos, Calif., 1984. 
(Chapters 1 and 2 contain salient articles on 
vector architectures.) 

5. K. Hwang and F. Briggs, Computer Archi¬ 
tectures and Parallel Processing, McGraw- 
Hill, New York, 1984. 



Reader Service Number 2 


6. K.E. Batcher, “Design of a Massively Paral¬ 
lel Processor,” IEEE Trans. Computers, 
Vol. C-29, Sept. 1980, pp. 836-844. 

7. T. Kohonen, Content-Addressable Memo¬ 
ries, 2nd edition, Springer-Verlag, New 
York, 1987. 

8. H,T. Kung, “Why Systolic Architectures?,” 
Computer, Vol. 15,No. l,Jan. 1982, pp. 37- 
46. 

9. H.J. Siegel, Interconnection Networks for 
Large-Scale Parallel Processing: Theory 
and Case Studies, Lexington Books, Lex¬ 
ington, Mass., 1985. 

10. S.J. Stolfo and D.P. Miranker, “The DADO 
Production System Machine,” J. Parallel 
and Distributed Computing, Vol. 3, No. 2, 
June 1986, pp. 269-296. 

11. V. Srini, “An Architectural Comparison of 
Dataflow Systems,” Computer, Vol. 19, 
No. 3, Mar. 1986, pp. 68-88. 

12. P.C. Treleaven, D.R. Brownbridge, and 
R.P. Hopkins, “Data-Driven and Demand- 
Driven Computer Architecture,” ACM 
Computing Surveys, Vol. 14, No. 1, Mar. 
1982, pp. 93-143. 

13. S-Y. Kung et al., “Wavefront Array Proces¬ 
sors — Concept to Implementation,” Com¬ 
puter, Vol. 20, No. 7, July 1987, pp. 18-33. 

14. G.J. Lipovski and M. Malek, Parallel 
Computing: Theory and Comparisons, 
Wiley and Sons, New York, 1987. (Includes 
reprints of original papers describing recent 
parallel architectures.) 



Ralph Duncan is a system software design 
consultant with Control Data’s Government 
Systems Group. His recent technical work has 
involved fault-tolerant operating systems, par¬ 
allel architectures, and automated code genera- 

Duncan holds an MS degree in information 
and computer science from the Georgia Insti¬ 
tute of Technology, an MA from the University 
of California at Berkeley, and a BA from the 
University of Michigan. He is a member of the 
IEEE and the Computer Society. 

Readers may contact the author at Control 
Data Corp., Government Systems, 300 Em¬ 
bassy Row, Atlanta, GA 30328. 


COMPUTER 


















At Motorola Cellular, 
big thinking 
creates small miracles. 


Inthe rapidly growing cellular phone industry, Motorolais^. We've beat 
all competitors in the race to introduce the world's smallest hand-held 
personal cellular phone. We call it MicroTAC. Others call it a “miracle” 
of big thinking.. .amajortechnologicaladvancein microchips, circuit 
boards and the manufacturing process. And this is just one of the 
breakthroughs resulting from the insights and ideas of Motorola 
engineers, who are making a big impact on communications by mak¬ 
ing the worldwide telecommunity smaller. 

If you want to shape the future of cell ular technology, consider one of 
the following opportunities: 


standards, ISDN standards, processor architectures, high-speed logic; 
16-bit MPU design practices, programmable logic; digital modulation 
synchronization, adaptive signal processing, viterbi algorithm and 
MLSE, decision Feedback equalizer; convolutional code and linear 
block code, speech coding, echo cancellation, encryption; CAE 
techniques for digital hardware design using Mentor Graphics, etc.; 
data communications protocols (CCITT *7, OSI, X.25, X.75, PAD, 
LAPB, LAPD, Ethernet, ISDN, CCITT V series modem, group 3 fax); 
computer network management/administration (Apollo Sun, Mentor 
Graphics, AppleTalk). BSEE/MSEE/BSCE/BSCS or equivalent. Re¬ 
spond to Dept. EC. 


SOFTWARE: Real-time software development using C, UNIX' 
Pascal, Ada, assembler and structured design; experience in soft¬ 
ware quality, metrics, ortesting; CASE software tools (Sun, Apollo); 
design, programming and system debugging for 
telephone digital switching or data communication 
systems; assembler and high-level structured 
languages; hardware diagnostics; object oriented 
design, C++; software development tools such as 
Teamworkand Interleaf; ASN.1 (Abstract Syntax Nota¬ 
tion); data communications protocols (CCITT *7, OSI, 

X.25, X.75 PAD, LAPB, LAPD, Ethernet, ISDN, 

CCITT V series modem, group 3 fax); model¬ 
ing and simulations(GPSS, SIMSCRIPTand 
other simulation tools). BSEE/BSCS/BSCE 
or equivalent. Respond to Dept. SW. 

ELECTRICAL/COMPUTER: Analog and 
RF circuit design, receiver or transmitter 
RF circuits; LCD display technok 
acoustics, and 8-bit microprocessor i 
ware; infrared and fiber optics; low speed 
data; digital modulation; 900 Mhz RF 
power amplifier design with hybrid or 
microstrip circuitry; RF device develop¬ 
ment with device vendors; parallel and/or 
push-pull RF amplifier design at 900 
Mhz or UHF; A/D and D/A convertors; 

RF propagation; passive and active 
filter theory; microwave antenna . 
design; UL, EMI and RFI require¬ 
ments; HP 3062 test system; HP 9000; 
digital hardware, microprocessor ap¬ 
plications and interfaces; digital switch¬ 
ing technology; firmware develop- 
ment methodology; PCM and digital i 
telephony; digital signal process¬ 
ing; ASIC design; LAN systems, PSTN 



MECHANICAL: Electronic packaging; CAD, CV CADDS 4X; 
materials selection and geometric tolerances and dimension- 
ing; extruded metal; injection molded plastics; 
life test procedures and factory introduction and 
support; plating materials and processes; structural 
analysis modeling; die casting and sheet metal 
stampings; thermal management. BSME/ MSME 
or equivalent. Respond to Dept. ME. 

SYSTEMS: Radio/cellular communication 
jngineering; RF propagation prediction 
methods; PSTN traffic planning; telephone net¬ 
work, interconnection and telecommunication 
industry standards; microwave system design 
and equipment engineering; telephone 
switching systems; software programming 
skills. BSEE/BSCE/BSCS or equivalent. Re¬ 
spond to Dept. S. 

For a future with a company that will value 
and encourage your ideas, come to 
Motorola Cellular where you’ll find the chal¬ 
lenges for your big thinking. We offer an ex¬ 
cellent salary and a comprehensive bene¬ 
fits package. For immediate consideration, 
send your resume to: Supervisor, Pro¬ 
fessional Recruitment, Motorola, Inc., 
Cellular Group, 1501 West Shure Drive, 
Arlington Heights, IL60004. Or FAX your 
i resume to: (708) 632-5717 (our 24-hour 
& FAX line). To access our On-Line 
Mk Career Network from your PC, dial 
K (508) 263-3857, press return twice 
and key in password LEGACY. We 
HjL are an equal opportunity/affirma- 
Ek tive action em ployer. 

§B -Registered trademark of AW 


0 MOTOROLA 

Cellular Group 





Databases and Cell- 
Selection Algorithms for 
VLSI Cell Libraries 


Simon Y. Foo, Florida State University/Florida A&M University 
Yoshiyasu Takefuji, Case Western Reserve University 


D esigning a system with library 
cells resembles putting one to¬ 
gether with off-the-shelf vendor 
ICs. Library cells have different specifica¬ 
tions ranging from I/O buffer options to 
internal gates with varying degrees of drive 
capability. For example, a function can be 
implemented in various structures, with a 
choice of buffers and I/O port locations. 
These essential implementation alterna¬ 
tives allow designers to explore new chip 
architectures using different cell structures 
with varying design constraints, such as 
speed, chip area, and power consumption. 

As the complexity of VLSI circuits con¬ 
tinues to grow, the need for a common, 
shared cell library is becoming inevitable. 
This is particularly true because of the 
diverse technologies that have evolved 
during the computer age — for example, 
the bipolar junction transistor (BJT), n- 
channel metal-oxide semiconductor 
(NMOS), complementary MOS (CMOS), 
gallium arsenide (GaAs), and bipolar MOS 
(BiMOS). 

Bipolar technology, particularly the 
advanced low-power Schottky (ALS) se¬ 
ries, is still very popular due to its very 
high-speed switching capability (as in the 
case of emitter-coupled-logic (ECL)) and 
the gradual reduction in power consump¬ 
tion due to improved processing tech¬ 
niques. MOS technology is most appropri¬ 
ate for prototyping VLSI circuits due to its 
high-density packing capability, relatively 


L. . . I 

This framework for 
capturing design data is 
based on semantic 
networks. It is well 
suited for application- 
specific ICs, yet general 
enough for other CAD/ 
CAM environments. 


simple processing steps, and low power 
consumption (as in the case of CMOS). 
GaAs technology is used primarily in mili¬ 
tary applications due to its extremely high¬ 
speed switching, high temperature opera¬ 
tion, low internal power dissipation, and 
antiradiation properties. But, as improved 
GaAS chip fabrication processes bring 
costs down, commercial applications will 
become feasible. 

Recently, processes have been success¬ 
fully mixed on a single silicon wafer — for 


example, BiCMOS technology, where the 
goal is to approach the high-speed switch¬ 
ing of BJT and low power consumption of 
CMOS. To have the greatest possible util¬ 
ity, a shared cell library will allow the 
complete spectrum of functions, imple¬ 
mentation alternatives, and process tech¬ 
nologies. 

Issues 

Although there has been considerable 
interest in using commercial database 
management systems for managing VLSI 
CAD data, the complex nature of VLSI 
design limits their suitability. Most gen¬ 
eral-purpose DBMSs are simply too slow, 
expensive, and inefficient for VLSI CAD 
applications. 1 Thus, current research on 
design data management in CAD environ¬ 
ments focuses on extensions or modifica¬ 
tions to support 

(1) efficient spatial searching, 

(2) design hierarchies and multilevel 
representations, 

(3) design alternatives and version 
control, 

(4) interface to simulation tools, 

(5) common interface between cell li¬ 
braries from different IC vendors, 
and 

(6) efficient cell selection based on 
given design constraints. 
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Figure 1. Phases of an IC design system based on a top-down methodology. 


Spatial searching. In human-machine 
design interactions, the human verification 
process depends on machine spatial 
searching to display selected portions of 
the VLSI design. Efficient spatial search¬ 
ing is essential to high performance and 
fast turnaround. Popular layout editors, 
such as UC Berkeley’s Kic and Magic, use 
a geographic bin structure for spatial in¬ 
dexing. Existing commercial DBMSs do 
not support such capabilities and, conse¬ 
quently, must rely on exhaustive search. 

Design hierarchies. Most CAD envi¬ 
ronments require hierarchical levels of 
abstraction. Typically, VLSI designs can 
be described at the functional, logical, cir¬ 
cuit, and layout levels. System architects, 
operating at the top level in the design 
hierarchy, rarely work with transistors and 
device models; at the bottom level, layout 
experts hardly ever access system-level 
descriptions. However, these tasks must be 
well coordinated by a group manager 
supervising the entire design process from 
concept to silicon. 

Figure 1 shows a typical flow of opera¬ 
tions in an IC design cycle based on a top- 
down methodology. Behavioral represen¬ 
tations, in text or equation form, describe a 
circuit’s function. For example, proce¬ 
dural descriptions, such as “If clock is high 
then increment counter,” and Boolean 
expressions, such as “Y = !A + B,” are 
functional representations; they do not 
specify details about implementation. 
Structural representations describe the 
composition of circuits in terms of cells 
(components) and interconnections among 
components. Such descriptions are usually 
hierarchical due to the composite nature of 
VLSI circuits. Block diagrams, circuit 
schematics, and netlists of logic gates are 
typical examples of structural descrip¬ 
tions. Physical representations show the 
circuit’s geometric layout on semiconduc¬ 
tor layers (polysilicon, diffusion, etc.) but 
do not convey information about function¬ 
ality. Hence, a snapshot of the design pro¬ 
cess at each level of abstraction requires a 
multilevel representation. 

Version control. To achieve fast turn¬ 
around (rapid prototyping) of high-per¬ 
formance VLSI chips, it’s often desirable 
to consider many alternative designs. 
Much of VLSI design is evolutionary or 
exploratory, so the database must support 
design versions and alternatives. Versions 
are improvements or modifications to a 
design object, while alternatives are differ¬ 
ent implementations of the same object 


with varying performance characteristics. 
For example, the process of partitioning or 
synthesizing a function into a structure of 
components is not unique; usually several 
alternatives can be considered. Consider 
the following alternatives: the next-state 
function in a control unit can be imple¬ 
mented as a one-way or two-way branch; 


multiple inputs to a functional unit can be 
made via a bus or a multiplexer; an adder 
can be designed as a ripple-carry, carry- 
save, or carry-look-ahead adder; a digital 
IC chip can use a one- or two-phase clock¬ 
ing scheme; I/O ports can be on different 
sides of a cell; a cell layout can have differ¬ 
ent aspect ratios of transistors, and so forth. 
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Common database 


Figure 2. Contrasting CAD systems: (a) independent nonstandard; (b) inte¬ 
grated. 


Tool interface. Besides representing 
domain-specific data, a dedicated VLSI 
database system should interface with 
other CAD tools. There is a need to repre¬ 
sent cell specifications/characteristics ex¬ 
tracted from circuit simulators (such as UC 
Berkeley’s SPICE (Simulation Program 
with Integrated Circuit Emphasis)) and 
timing analyzers (such as UC Berkeley’s 
Crystal) in a common database. Currently, 
simulations are performed independently, 
and the results are loosely organized in a 
rather ad hoc manner. UC Berkeley’s Oct 
tools exemplify recent attempts to solve 
this problem. The Oct package includes an 
object-oriented database manager for 


VLSI CAD and interfaces with other popu¬ 
lar VLSI tools readily available to univer- 


Library interface. Sharing cell librar¬ 
ies helps prevent duplicate development 
efforts and promotes exchange of ideas for 
new cell architectures. Recent attempts 
include an NMOS library 2 and a CMOS3 
(three-micron CMOS technology) cell li¬ 
brary 3 consisting of contributions from 
various sources. The fabricated cells are 
functionally tested and characterized, then 
catalogued in a manner similar to IC data 
books. However, differences in cell speci¬ 
fications, from I/O-buffer options to inter¬ 


nal gates, have often discouraged the shar¬ 
ing of cell libraries. 

A standard format for documenting cells 
or a common interface for interlibrary 
communications is needed so that IC de¬ 
signers can concentrate on the design 
phase. One solution is offered by design 
languages, such as AHPL, that formalize 
the design process by interconnecting 
small-, medium-, and large-scale-integra¬ 
tion subsystems. AHPL offers a conven¬ 
ient, unambiguous means for expressing 
and communicating a design at the regis¬ 
ter-transfer level. Recently, there has been 
much pressure on commercial IC vendors 
to adopt the Electronic Design Interchange 
Format (EDIF) as the industry’s standard 
design interchange language. In contrast to 
AHPL, EDIF resembles a symbolic layout 
language. It supports design description at 
several levels of abstraction, including 
mask and symbolic layout levels. Recent 
EDIF activities include UC Berkeley’s 
project to support the EDIF 2.0.0. stan¬ 
dard. The EDIF Software Project’s goal is 
a translator-building toolkit that will pro¬ 
vide facilities needed for EDIF transla¬ 
tions. 

Cell selection. The last issue concerns 
the familiar problem of combinatorial 
optimization. Cell selection involves 
choosing from a list of possible candidates 
an implementation that meets system re¬ 
quirements. The choice is often influenced 
by design constraints such as speed, area, 
power, fan-out, complexity, architecture, 
and reliability. Selection algorithms can 
help prune the design search space, thereby 
providing near-optimum decisions on cell 
selection. This process is particularly 
important in the design of application- 
specific ICs, where a high degree of per¬ 
formance and optimization is desirable. 

In general, our article represents a sur¬ 
vey of approaches addressing four of the 
six issues just defined. That is, we cover 
design hierarchies and multilevel repre¬ 
sentations, design alternatives and version 
control, common interface between cell 
libraries, and efficient cell selection based 
on given design constraints. 

Background 

Consider an independent nonstandard 
CAD system (Figure 2a) where each appli¬ 
cation tool has its own unique database. 
Communication between tool i and tool j is 
via interface (i, j). The total number of 
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interfaces required for n tools is n(n - 1) / 
2, that is, the number of interfaces required 
to implement a complete CAD system 
grows exponentially as the number of tools 
increases. In contrast, an integrated CAD 
system (Figure 2b) consists of a set of tools 
tightly coupled to a common database 
through a standard set of tool interfaces. 
Besides the advantages of a common data¬ 
base, the integrated CAD system is also 
modular, that is, application tools can be 
“plugged” in or taken out without recon¬ 
figuring the common database. 

The desire for such an integrated CAD 
system brings us to the concept of CAD 
frameworks. Basically, a CAD framework 
is a software system into which separate 
application tools, such as schematic edi¬ 
tors, simulators, and IC or printed-circuit- 
board layout tools, can be plugged. A CAD 
framework also includes front-end soft¬ 
ware that manages a tool’s appearance on 
the computer user’s terminal, back-end 
software that tracks the enormous data 
required to design a complex VLSI system, 
and key utilities that help manage multiple 
teams of designers. 

Most VLSI chip manufacturers offer 
their own in-house CAD framework, but 
standards are now being developed to 
support the concept of painlessly plugging 
different application tools into frame¬ 
works from different manufacturers. The 
CAD Framework Initiative (CFI) is an 
industry-sponsored effort to standardize 
interfaces between VLSI CAD tools. CFI 
is seeking a set of standards for design- 
automation tools that would allow end- 
users to “mix and match” their own design 
systems. Such standards would give IC 
designers rapid access to new CAD soft¬ 
ware technology from multiple vendors. 

The need for standardization — and its 
potential benefits — was succinctly stated 
in the September 1989 SIGDA Newsletter. 

. . . The need for industry-compatible CAD 
frameworks has become more acute in recent 
years with the emergence of the commercial 
CAD industry and the increasing complexity 
of designs. As new IC designs approach one 
million transistors and electronic systems 
are ten to a hundred times more complex, the 
CAD support environments have become 
slow and cumbersome. Many observers feel 
the standardization of CAD environments is 
the single most important factor in providing 
the design productivity required for these 
next-generation efforts. 

The CFI board, representing more than 40 
major IC design companies, has since set 
up seven committees to study VLSI CAD 
issues ranging from design data-manage- 
ment techniques to user interfaces. 


Data models and 
design data 
management 

Data models. The database models 
applied in today’s database systems gener¬ 
ally fall into one of the following catego¬ 
ries: 


• hierarchical, 

• network, 

• relational, or 

• semantic. 

A hierarchical schema consists of a col¬ 
lection of record types and a collection of 
link types that specify connections be¬ 
tween the record types. The restriction is 
that each record type in a given tree (with 
the exception of the root type) must be the 
child type of a single parent record type. 
Hence, a hierarchical database consists of 
a “forest” of trees, conforming to the struc¬ 
ture defined in the schema. 

The network data model is similar to the 
hierarchical model, except for two distinct 
features. First, it permits multiple link 
types between record types. Second, a 
given record can have multiple parent rec¬ 
ords. Consequently, the network data 
model is more flexible than the hierarchi¬ 
cal model. 

In contrast, a relational database con¬ 
sists of n-ary relations, where each relation 
may be viewed as a table with a fixed 
number of named columns and a variable 
number of rows. The rows in each table are 
called tuples, and the columns are referred 
to as attributes. The relationships between 
the data records are called sets. Relational 
operations on the database, such as 

• form subsets of rows or columns, 

• form the union, difference, or intersec¬ 
tion of sets, and 

• combine relations by concatenating 


can be performed using a data manipula¬ 
tion language. Data manipulation lan¬ 
guages for the relational data model are 
typically derived from a relational calculus 
or a relational algebra. The relational data 
model overcomes the record-oriented limi¬ 
tation of the hierarchical and network 
models by allowing many-to-many rela¬ 
tionships without pointer overhead. 

A fundamental problem with the hierar¬ 
chical, network, and relational data models 
is their limited semantic expressiveness. 
Semantic data models, on the other hand, 


use static constructs to represent object- 
object, type-type, and type-object relation¬ 
ships. One of the major features of the 
semantic data model is the ability to inherit 
attributes from types to objects. The ob¬ 
ject-oriented model and the semantic 
(frame-based) network model , are vari¬ 
ations of the semantic data model. 

Object-oriented programming systems 
(OOPSs), such as Smalltalk, C++, and the 
Common Lisp Object System, are based on 
the object-oriented data model. Central to 
the object-oriented data model is the con¬ 
cept of a class (sometimes referred to as 
type), which is a collection of data items 
defining the state of an instance (or object) 
of the class, and a set of functions to man¬ 
age that state. An instance is a unique copy 
of the collection of data items belonging to 
a particular class. Each data item is called 
an instance variable, and the functions of 
the class are referred to as methods. The 
primary feature of an OOPS is the concept 
of inheritance, which allows us to specify 
a new class by defining only the differ¬ 
ences between it and another class (called 
its superclass). For example, we could 
specify a class “half-adder” by declaring it 
a subclass of “full-adder” and describing 
the differences. Then, full-adder becomes 
the superclass of half-adder. 

In frame-based systems, instances are 
frames (or generalized property lists) and 
instance variables are called slots. Frame 
systems often include runtime support for 
expressing relationships between instance 
records. For example, there are built-in 
facilities that search the frame networks 
for sets of instances that resemble but do 
not exactly match each other. Such support 
is often built on top of a conventional 
OOPS. 

Design data management. Currently, 
there are four major approaches to effec¬ 
tive management of data in VLSI CAD 
applications: 

(1) developing a special-purpose de¬ 
sign DBMS (DDBMS), 

(2) enhancing a current DBMS by add¬ 
ing new capabilities and functions, 

(3) building a layer of software on top 
of a current DBMS to compensate 
for deficiencies, and 

(4) using a special-purpose file man¬ 
ager that views the DBMS as an ap¬ 
plication. 

Ketabchi and Berzins 4 provide an ex¬ 
ample of the first approach. They proposed 
an object-oriented data model as a frame- 
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Figure 3. Three possible architectures for the XOR function: (a) based on trans¬ 
mission gates; (b) gate-array implementation; (c) unoptimized combinational 
logic circuit. 


work for achieving effective management 
of versions (refinements) and alternatives 
of composite objects in CAD applications. 

The second approach requires extensive 
enhancements to the current DBMS, as 
reported by Lorie and Plouffe 5 and Stone- 
braker. 6 Lorie and Plouffe discussed ex¬ 
tensions to System R, while Stonebraker 
worked on enhancements to Ingres based 
on the applications of abstract data types 
and abstract indices. However, this ap¬ 
proach is not very satisfactory because its 
extra overhead slows down the DBMS. 

The third approach is attractive because 
it runs user-application programs on top of 
a general-purpose DBMS and thus be¬ 
comes operational rapidly. For example, 
Ingres provides user interfaces through 
high-level programming languages such 
as C, Pascal, and Fortran. However, this 
approach is inefficient because user pro¬ 
grams must be linked to all Ingres database 
functions, but only a few features are used 


frequently. Furthermore, Ingres requires 
enormous memory space during program 
runtime. 

Katz et. al. 7 used the fourth approach. 
Their version server organizes design data 
and provides mechanisms, such as object 
check-in and check-out, for controlling 
design evolutions. Design objects are 
connected using version, configuration, 
and equivalence relationships that form 
orthogonal, hierarchical name spaces for 
logically grouping design objects. This 
approach, however, does not take advan¬ 
tage of capabilities, such as data encapsu¬ 
lation, provided by high-level data models 
and database technology. 

Some researchers claim that object-ori¬ 
ented database management systems 
(OODBMSs) offer several aids to rapid 
prototyping of VLSI designs. For example, 
Batory and Kim 8 introduced an object- 
oriented Smalltalk-style model where 
generic objects and version objects be¬ 


come types and instances, respectively. 
Instances can inherit attributes from their 
individual types, similar to generalization 
hierarchies in semantic data models. Gupta 
et. al. 9 described their use of Cbase, a VLSI 
CAD framework developed at the Univer¬ 
sity of Southern California. Cbase uses 
OODBMS concepts and provides a plat¬ 
form for creating, displaying, manipulat¬ 
ing, and maintaining digital VLSI designs. 

Among other approaches is a data 
model, introduced by McLellan, 10 that 
groups cells into libraries and establishes a 
search path based on an ordered list of 
libraries. In Neuman’s" generalized ap¬ 
proach to CAD databases, the version 
server explicitly tracks versions but does 
not use timestamps to identify invalid 
equivalences. 

Version management in software devel¬ 
opment environments has been a matter of 
concern for some time, but capturing the 
semantics of design objects and version 
control has not yet been dealt with. For 
example, the Unix Source Code Control 
System maintains versions of files but has 
no knowledge of how they map onto a 
hierarchical configuration of program 
modules. Versions are named according to 
creation times. One of the shortcomings of 
SCCS is that it does not associate versions 
of component modules with the module 
that incorporates them. Some VLSI layout 
editors, such as Magic from UC Berkeley, 
incorporate a kind of version control in the 
form of a timestamp. Mismatches in the 
timestamps are reported when the compos¬ 
ite (leaf) cells of a root cell are altered, with 
or without the designer’s knowledge. 

As a case study of the special-purpose 
DDBMS approach, we’ll consider a frame- 
based model. We chose the semantic 
(frame) model because its hierarchical data 
structures support attribute inheritance and 
are well suited for representing VLSI de¬ 
sign data, which require hierarchical de¬ 
composition and multiple levels of abstrac¬ 
tion. The balance of this article discusses 
our frame-based database system. 

Frame-based model 

In our VLSI CAD environment, the 
design database can be modeled as a col¬ 
lection of atomic and composite objects. 
Primitives such as inverters, transmission 
gates (pass transistors), and two-input 
NAND and NOR gates are classified as 
atomic objects. Composite objects are 
made up of smaller components (atomic or 
composite) interconnected in a hierarchy 
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Figure 4. A frame-based schema for a design object. 


to perform a particular function. The leaves 
of the hierarchy are atomic objects, and the 
internal (intermediate) nodes are compos¬ 
ite objects. A composite object is described 
only once at the type level; when the object 
is instantiated, it becomes an instance (or 
cell). 

We adopted a variation of Magic’s tech¬ 
nique of labeling cell names, where each 
instance is denoted by 

<cell-type>_<tag>_<id> 

The identifier cell-type specifies circuit 
function (NAND, for example), tag identi¬ 
fies a particular implementation (or ver¬ 
sion) of cell-type, and id is the instantiation 
number, a function of the number of times 
an object type is instantiated in the global 
database. The concatenation of identifiers 
cell-type, tag, and id uniquely identifies an 


instance in a common database. 

For example, consider the circuit im¬ 
plementation of the exclusive-OR (XOR) 
function. Figure 3 shows a set of possible 
implementations of the function F = AB' + 
A'B. The list of cell-types used in a com¬ 
posite object can be derived by taking the 
uniqueness of cell-types used in a list of 
instances. For the XOR gate in Figure 3b, 
the complete list of instances used in the 
composite object is 

(nand_A_0, nand_A_l, nand_A_2, 
nand_A_3} 

where the cell-type used is “nand” gate and 
the tag is “A.” 

Each design object is described by a set 
of views (documentation, switching char¬ 
acteristics, I/O interface, etc.). In a seman¬ 
tic network, each frame represents a par¬ 


ticular view. Therefore, a design object 
can be represented by a hierarchical struc¬ 
ture of frames, as shown in Figure 4. The 
dependency between the views is repre¬ 
sented by the hierarchical structure of the 
corresponding frames. 

The root frame may contain slots speci¬ 
fying the specialization and aggregation 
of the instance. Specialization is repre¬ 
sented by an is-a or AKO (a-kind-of) link, 
while aggregation (or parts relationship) is 
represented by parent-of (or owner-of) and 
child-of (or belong-to) links. The type slot 
is used to specify a particular implementa¬ 
tion of a function (for example, carry-save 
adder) or a unique characteristic of a cell 
(for example, up-down counter). 

The documentation frame describes the 
legal aspects of a cell. The file slot speci¬ 
fies the directory path for accessing the 
layout file. The state of the design process. 
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Figure 5. Tree representations of a design object. Notice the additional slots, “belong-to” and “owner-of,” containing point¬ 
ers to other trees. 


whether it has been functionally simulated 
or its timing analyzed, is indicated in its 
status slot. In the case where the design has 
been fabricated and parametric testing 
performed on the IC chip, such progress 
should also be noted in the status slot. 

Each port frame describes the interface 


of one cell to other cells. The wirename 
slot indicates wire types (for example, 
signal, power, or ground), while the drive 
slot specifies fan-out capabilities. This 
information is essential for checking the 
I/O compatibility of each port before 
global routing or channel routing. 


The constraints frame typically speci¬ 
fies the physical dimensions of the Man- 
hattan-style cell layouts, in terms of width 
and height, and other equally important 
considerations, such as power consump¬ 
tion and propagation (or path) delay. 

Besides functional specifications, IC 
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designers are interested in dynamic and 
static cell characteristics (for example, 
propagation delay, fan-out, maximum 
clock frequency, and test conditions). 
Therefore, the propagation delay of each 
I/O node is represented by a data-sheet 
frame of the cell’s switching characteris¬ 
tics. For example, delay time and rise/fall 
time are specified under the following 
conditions: worst-case processing parame¬ 
ters, 5 volts, 125 degrees Celsius, and a 
typical loading of 1.5-kilohms lumped- 
series resistance and 1.5-picofarad load 
capacitance with an input transition time 
of 10 nanoseconds. The worst-case delay 
information is intended to be used for quick 
cell-to-cell performance comparisons. For 
each data sheet under a particular test 
condition, there is one set of switching 
characteristic data for each fan-out load. 
Hence, there is a separate data frame con¬ 
taining the rise/fall times of a cell driving 
a particular fan-out load. 

Mapping design objects onto tree 
structures. Based on the above schema, 
we defined a set of rules for mapping de¬ 
sign objects from the frame-based repre¬ 
sentation (shown in Figure 4) to tree repre¬ 
sentations such that the information about 
the design objects can be stored or manipu¬ 
lated. There are two major rules: 

(1) Attributes of one-to-one (1:1) rela¬ 
tionships between a parent frame and a 
child frame are merged into a single tree 
with the parent’s node as the root. 

(2) In the case of one-to-many (1: N) 
relationships between a parent and its child 
frames, a separate tree is created for each 
child frame. Each child frame is connected 
to its parent through the belong-to slot and 
each parent to its child frames via the 
owner-of slot.. 

Figure 5 shows the corresponding tree 
representation of the frame-based schema 
(shown in Figure 4) after the mapping 
process. Attributes of the documentation 
frame, along with the area and power at¬ 
tributes of the constraints frame, are 
merged onto the parent tree since these 
attributes are one-to-one relationships. 
However, subtrees are created for ports 
since each cell has more than one I/O port. 
Separate trees are also established for the 
data sheets since each cell has at least one 
set of timing data. Also note that additional 
slots, belong-to and owner-of, containing 
pointers to other trees are created as a 
result of the second mapping rule. 


Table I. Switching characteristics of an XOR cell. 
(Vdd = 5V; input transition time = 5 ns) 


Parameter 


load = 1 
(typical) 

Fan-out 

load = 10 
(typical) 

Propagation delay 
(high to low) 

tpHL 

7.5 

11.5 

Propagation delay 
(low to high) 

tpLH 

7.0 

19.0 

Output fall time 

tTHL 

7.0 

12.5 

Output rise time 

tTLH 

12.5 

40.5 


Manipulating the 
design database 

Following the conversion of frames to 
trees, information can be appended to the 
cell database through an operation 

fput(<object>; <constraint> <value>; 

...) 

where fput is a procedure for performing 
the append operation, the object argument 
specifies the identifier of a frame or node, 
the constraint slot specifies an attribute, 
and one or more values are assigned to that 
attribute. For example, consider the 
switching characteristics of a tested XOR 
cell from a library, 12 as shown in Table 1. 
The timing information is appended to the 
design database through the following 
append operations: 

fput(XX7486; 
is_a “XOR”; 
bit_size 2; 

owner_of “datasheetl”; 
power 0.2; 

status “SPICEd, Crystaled”; 
technology “CMOS”; 
file “library/cells/XX7486.mag”; 
designer “UW/NW-VLSI”) 

fput(datasheetl; 

belong_to “XX7486”; 
owner_of “datal, data2”; 
vdd 5; 

input_transition_time 5) 
fput(datal; 

belong Jo “datasheetl”; 


fanoutjoad 1; 
tpHL 7.5; 
tpLH 7.0; 
tTHL 7.0; 
tTLH 12.5) 

fput(data2; 

belong_to “datasheetl”; 
fanoutjoad 10; 
tpHL 11.5; 
tpLH 19.0; 
tTHL 12.5; 
tTLH 40.5) 

Pointers under slots owner_of and 
belongjo link the parent and child nodes. 
Units of transition, voltage, and DC power 
consumption are assumed to be in nano¬ 
seconds, volts, and milliwatts, respec¬ 
tively. Notice that the popular TTL (tran¬ 
sistor-transistor logic) catalog numbering 
of cells is still applicable in a CMOS li¬ 
brary; that is, in XX7486 above, XX is the 
manufacturer’s standard prefix, 74 denotes 
manufacturer’s specifications to meet 
commercial applications (54 would denote 
military specifications), and 86 is a TTL 
number for XOR logic gate. Also, tpHL 
and tpLH stand for time of propagation 
from high to low and low to high, respec¬ 
tively; tTHL and tTLH stand for time of 
transition from high to low (output fall 
time) and low to high (output rise time), 
respectively. 

Daemons. Functions automatically ac¬ 
tivated in response to the need for a value, 
or its placement or removal, are called 
daemons. Therefore, these functions are 
called if-needed, if-added, and if-removed 
daemons. An example of a demand-driven 
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Query#l: 

Returns: 

fget(*) 

A list of all instances and classes available in the database, 
where wild-card indicator “*” means “match all.” 

Query#2: 

Returns: 

fget(*; *; *) 

All existing information available in the database. 

Query#3: 

Returns: 

fget(74HC74; *; *) 

All existing information about instance “74HC74.” 

Query #4: 
Returns: 

fget(74HC74; *) 

A list of attributes associated with “74HC74.” 

Query #5: 
Returns: 

fget(74HC74; function; status; technology) 

A list of requested information about “74HC74.” 

Query #6: 
Returns: 

fget(register; where bit_size = 4 & designer = “foo”) 

A list of 4-bit registers designed by “foo.” 

Query#7: 
Returns: 

fget(*; where designer = “foo”) 

A list of all instances designed by “foo.” 

Query#8: 

Returns: 

fget(comparator) 

A list of all instances of object type “comparator.” 

Query#9: 

Returns: 

fget(adder; where bit_size = 4 
& path_delay> = 5.0 & path_delay <= 10.0) 

A list of all 4-bit adders with path-delay ranging from 5.0 to 10.0 ns. 

Query# 10: 
Returns: 

fget(*; where parent_of = “74HC74”) 

A list of composite objects where “74HC74” has been instantiated. 

Query#l 1: 
Returns: 

extract(“74HC74,” complete) 

A complete list of atomic and composite objects 
belonging to “74HC74.” 

Query#12: 

Returns: 

extract(“74HC74,” unique) 

A list of unique objects (atomic and composite) 
belonging to “74HC74.” 


Figure 6. Example queries demonstrating language features. 


if-needed daemon is the area-calculating 
function, which can be applied to all in¬ 
stances with Manhattan-style geometries. 
Given the width and height of a cell, for 
example, 

fput(74HC74; width 210; height 196) 

the function “area = width x height” will 
return a value of 41,160 if queried. The 
database does not store this value because 
it can be automatically computed if 
needed. This area-calculating function is 
always “lurking” inside the program, 
hence the term “if-needed daemon.” 

The expertise of IC designers can be 


captured with artificial intelligence tech¬ 
niques. This expertise can take the form of 
procedural knowledge, for example, a set 
of procedures to calculate the passive com¬ 
ponent values for a differential amplifier, 
given specifications of gain, output imped¬ 
ance, common-mode rejection, etc. 

Due to the nature of VLSI CAD data, 
simple expertise for manipulating domain- 
specific data can be captured in the form of 
procedural knowledge. This knowledge, 
represented by a set of rules, is useful for 
handling incomplete or plausible informa¬ 
tion through deductive inferences on the 
design database. These rules can be imple¬ 
mented as daemons, for example. 


for each instance 

if function is digital comparator 
then number of outputs is 3; 
if status is tested 

then all subcells are tested; 
if technology is CMOS 
then all subcells use CMOS; 
and so forth. 

The above rules may seem trivial, but 
they are useful in enforcing integrity con¬ 
straints on the design database. Since they 
are invoked when information is appended, 
the rules are implemented as if-added 
daemons. If certain instances are deleted 
from the database as part of the design 
process, links between the parent cell and 
its child cells are also deleted through the 
if-removed daemon. 

Query language for relational opera¬ 
tions. Information can be retrieved using a 
query language capable of performing re¬ 
lational operations in a frame-based sys¬ 
tem. The syntax for the query operation 
used in our frame-based system is 

fget(<object> {;conditional 
expressions> I <target slots>}) 

where function fget returns a list of infor¬ 
mation that satisfies the conditional ex¬ 
pressions or is stored in the target slots. 
Conditional expressions are lists of con¬ 
straints (numerical or symbolic) with rela¬ 
tional arithmetic operators (for example, 
=, <, and >) and logical connectives (for 
example, AND, OR, and NOT), while tar¬ 
get slots are object attributes. In general, 
conditional expressions are used for selec¬ 
tion queries, while target slots are used for 
projection queries. Numerical range can be 
specified by a conjunction of two numeri¬ 
cal constraints as follows 

<slot><relational operatorxvalue 1 > 

& <slotxrelational 
operatorxvalue2> 

where “&” is the conjunction operator. For 
example, the constraint “20.00 < path-de¬ 
lay < 30.00” is represented as 

path_delay > 20.00 
& path_delay < 30.00 

The example queries in Figure 6 demon¬ 
strate a few features of the query language. 
Queries 1 through 5 are called projections, 
while queries 6 through 10 are selection 
operations as used in relational databases. 
In addition to the fget function, there is an 
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(1) Group candidates into a preliminary cell-list P(/) 

/* P contains a list of possible candidates that satisfy the design 
specification (e.g., bit-size, etc.) for each function/*/ 

(2) for each empty preliminary list, announce failure for/. 

(3) Create a working list W consisting of the first instances 
from each nonempty preliminary list. 

(4) for each instance in W, 

apply rule-set; 
if any rule is fired then 
append instance to S; 

/* S = { final selected cells } */ 
else the function of the particular instance is tagged “problem,” 
and the “problem” function is appended to F. 

/* F = { problem functions } */ 

(5) for each “problem” function of F, 

if preliminary list is empty then announce failure and exit; 
else choose the next instance from the preliminary list and update W, 
and goto step 4. 

/* Backtrack and choose new instance */ 

(6) Return S. 


Figure 7. Cell selection scheme based on a backtracking algorithm. 


extract function that recursively traverses 
the component cells of a particular instance 
and returns a list of all subcells (nodes). For 
example, queries 11 and 12 will traverse 
the tree of instance 74HC74, from the root 
node down to the leaves. It is also possible 
to traverse the first layer of intermediate 
nodes beneath the root. Reserved key iden¬ 
tifiers, “complete” and “unique,” specify 
whether the returned list is a complete tally 
of all instances or a list of unique object 
types only. 

Cell selection 

The query language described above can 
aid IC designers in choosing appropriate 
cells from a frame-based VLSI cell library. 
Choosing cells for VLSI circuit design 
generally depends on four major catego¬ 
ries: function, propagation delay, area, and 
power consumption. These categories can 
be subdivided into sets of attributes. For 
example, attributes bit-size and type sup¬ 
plement the category function, where type 
is used to specify a particular implementa¬ 
tion of the function. Category propagation- 
delay is usually described by a set of attrib¬ 
utes such as the minimum, maximum, and 
typical delay associated with a particular 
fan-out load. 

To aid cell selection, IC designers cur¬ 
rently use verification tools for functional 
simulation and timing analysis. Previous 
work in cell selection includes the LSMS 
(logic synthesis and module selection) step 
of Carnegie Mellon University’s Design 
Automation Project, which used a set of 
predictors to estimate achievable bounds 
of cost, delay, and power parameters. 

Our approach to cell selection is based 
on the following sequence of tasks: 

(1) Normalize and rank the constraint 
data. 

(2) Apply the search algorithm. 

Normalizing design constraints. Sta¬ 
tistics on area and power consumption can 
be retrieved directly from the cell data¬ 
base. The value for path-delay is assumed 
to be the worst-case propagation delay, 
where 

worst-case propagation delay 
= maximum(tpHL, tpLH) 

In the XX7486 example (with the timing 
data shown in Table 1), the path-delay 
value is derived by traversing the XX7486 
tree using pointers in the owner-of and 


belong-to slots. Consequently, 

path-delay [XX7486] 

= maximum(l 1.5, 19.0) 

= 19.0 ns for fan-out load of 10 

For each cell, statistics on path-delay, 
area, and power consumption are quan¬ 
tized (normalized) and ranked on a scale of 
0.0 to 10.0 (least to most critical) by 

rank= scale X (1.0 - ((«[/] - min)/ 

(max - min))) if max # min 
= scale if max = min 

where a[i] is a constraint value for cell i. 
The value for scale is arbitrarily set at 10.0, 
while min and max are the global mini¬ 
mum and maximum values, respectively. 

The following example illustrates the 
ranking of design constraints: 

Instance Path-delay (ns) 
cell_i 20.0 

cellj 25.0 

cell_k 15.0 

From the above list of candidates, the 
following parameters are computed: 

max = 25.0 
min = 15.0 
rank of cell_i = 5.0 
rank of cellj = 0.0 
rank of cell_k = 10.0 


Therefore, celljc is the best candidate 
among the three cells in terms of path- 
delay. 

Prioritizing rules. Criteria for resolv¬ 
ing design trade-offs in terms of speed, 
area, and power can be obtained by speci¬ 
fying a weight for each constraint. This 
strategy of prioritizing the selection rules 
is simple but effective, as shown by a rule- 
base example: 

fput(rulel; path_delay 10.0; 

area 8.0; power 1.0) 
fput(rule2; path_delay 10.0; 

area 5.0; power 1.0) 
fput(rule3; path_delay 10.0; 

area 3.0; power 1.0) 
fput(rule4; path_delay 8.0; 
area 8.0; power 1.0) 

The constraint weights (ranging from 0 
to 10) are arbitrarily set by the user to 
specify their relative importance in the se¬ 
lection process. In the above rules, for ex¬ 
ample, path-delay is most critical and 
power is least important to rule 1. The rules 
are applied in ascending order. For ex¬ 
ample, if there exists among the candidates 
a celljc with path-delay ranked 10.0, area 
> 8.0, and power at least 1.0, then rulel is 
fired and cell_k is selected. If rulel is not 
fired, the next rule is applied and the proc¬ 
ess repeated until success is reported or the 
list of rules is exhausted. 
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SelectCells(function-list F) 

I 

Initialize selected cell-list S; 

for each function/in F, group cells which satisfy the design specifications 
into a cell choice list. 

for each empty choice list, announce failure for/ 
for each nonempty choice list, 

rank and sort instances under each constraint; 
apply rule-set to the first instance of the sorted list; 
if at least one rule is fired then 
append instance to S; 
notify user of the rule fired; 
else announce failure for/; 
return(S); 


Figure 8. Pseudocode (in C-like notation) of the non-backtracking algorithm. 



Figure 9. A vending machine system controller. 


Design trade-offs are resolved by em¬ 
phasizing the importance of each con¬ 
straint in a selection rule. For example, if 
area is critical, then more weight is placed 
on that attribute. The ordering of rules, 
along with their weight factors, allows user 
control of cell selection from a list of pos¬ 
sible candidates and resolves simple de¬ 
sign trade-offs. 

Backtracking algorithm. One ap¬ 
proach to the overall cell-selection scheme 
is based on the backtracking algorithm 
outlined in Figure 7 (preceding page). Es¬ 
sentially, the backtracking algorithm is an 
exhaustive search. It quits when the first 
solution is encountered or when the in¬ 
stance choice-list for a particular function 
is exhausted. The biggest drawback of this 
backtracking approach is that it does not 
optimize the solution (the selected cell 
set). Since candidates are not sorted, cells 
at the top of the lists are evaluated first; 
better candidates deep in the list may not 
be considered at all. However, for small 
lists and cases where optimized solutions 
are not important, this approach can be 
quite fast. 

Non-backtracking algorithm. The 

non-backtracking algorithm closely re¬ 
sembles the backtracking approach. The 
major difference is that the non-backtrack¬ 
ing algorithm relies on a sort routine that 
ranks and sorts possible candidates ac¬ 
cording to design constraints. Since the 
candidates are sorted, backtracking is net 
necessary. User-specified rules are applied 
successively, in descending order, to the 
list of candidates. Hence, unlike the back¬ 
tracking approach, the non-backtracking 
approach employs some form of optimiza- 

The pseudocode (in C-like notation) of 
the non-backtracking algorithm appears in 
Figure 8. Notice that each instance may 
satisfy more than one rule in a given rule 
set. In such cases, only the highest priori¬ 
tized rule is reported to the user. 


Test example 

We used the design of a prototype vend¬ 
ing machine to benchmark our selection 
algorithms, which ran on top of the frame- 
based database system. Figure 9 shows the 
vending machine’s system controller. 
Basically, it consists of an operation unit 
and a control unit. The operation unit 
consists of an adder, register, counter, and 
comparator. The control unit is imple- 
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merited using a programmable logic array 
(PLA) with input and output registers. The 
mnemonics for the control signals are 

CP: coin present 

CR: changer ready 

CA: clear accumulator 
DA: decrement accumulator 
PDR: pop drop ready 
GT: accumulated coin value 

greater than price 

EQ: accumulated coin value equal 

to price 

LT: accumulated coin value 

less than price. 

Assuming a four-bit data bus, the design 
specifications of the components imple¬ 
menting the system controller can be ex¬ 
pressed as 

fget(adder; where bit_size = 4 
& technology = “cmos”) 
fget(register; where bit_size = 4 
&type = “parallel-in/parallel-out” 

& technology = “cmos”) 
fget(counter; where bit_size = 4 
& type = “synchronous, up/down” 

& technology = “cmos”) 
fget(comparator; where bit_size = 4 
& technology = “cmos”) 

Notice that the cell database does not track 
the control unit, since it can be automati¬ 
cally generated using finite-state machine 
or PLA compilers. 

We evaluated performance of the selec¬ 
tion algorithms using a test database of 
dummy entries with randomly generated 
specifications. Figure 10 compares the 
backtracking and non-backtracking algo¬ 
rithms in terms of CPU access time on a 
VAX-11/780 minicomputer. The pro¬ 
grams are coded in C, and hash tables are 
used in both cases. Generally, the speed of 
the backtracking algorithm depends on the 
selection rules, that is, tougher criteria 
require more backtracking until a solution 
satisfies all the conditions in the rules. On 
the other hand, the speed of the non-back- 
tracking algorithm depends on the number 
of entries in the preliminary choice lists, 
that is, more entries mean a longer sorting 
time. With the preliminary choice lists 
sorted, the selection rules are applied only 
once, and backtracking is not required. 

Figure 10’s approximately linear curves 
confirm the algorithms’ exhaustive-search 
nature. The speeds can be dramatically 
improved if the parallelism inherent in our 
selection algorithms is exploited and the 
database has sophisticated access meth¬ 
ods. 


O verall, our case study supports 
the need for cell-selection mecha¬ 
nisms in integrated CAD or DA 
systems. The characteristics of our proto¬ 
type frame-based database system, espe¬ 
cially the strategy of specifying a weight 
factor for constraining selection rules, 
make it a valuable tool for ASIC design. 
Furthermore, the framework is general 
enough for other CAD-related applica- 

However, the selection algorithms have 
two limitations. First, they do not consider 
cell shapes and I/O positions, criteria that 
may be crucial for global routing of se¬ 
lected cells. Second, because of shape, the 
selection of one cell may affect the selec¬ 
tion of others. This interdependency needs 
to be properly identified and addressed. It 
is also possible that a particular cell’s rank¬ 
ing can be made dependent on the number 
of times it’s instantiated in the design data¬ 
base. 

In the frame-based system, using point¬ 
ers to parent-child relationships between 
frames requires a lot of extra memory. The 
approach is also prone to collapse of data 
integrity in the case of a fault in the pointer 
representations. In this aspect, relational 
databases such as Ingres are preferable 
because the relational data model uses a 
concatenation of keys instead of the single 
pointer used by the frame-based data 
model. 

On the other hand, the frame-based cell 


library for digital circuits can also be ap¬ 
plied to analog circuits. Information on 
analog circuits, such as gain and frequency 
response, and SPICE parameters, such as 
the transconductance parameter, channel 
length modulation parameter, threshold 
voltage, bulk threshold parameter, and 
channel surface mobility, can be encoded 
in a similar manner. 

Finally, our case study is not intended to 
favor independent CAD systems. Rather, 
it is an attempt to highlight major issues, 
ones we can all agree on, involved in build¬ 
ing a standardized, integrated CAD/CAM 
system. ■ 
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Design of a Bitmapped 
Multilingual Workstation 


Richard F. Walters 
University of California at Davis 


P roviding computer support for 
English text is simpler in several 
important respects than support¬ 
ing other natural languages. Most English 
words require no diacritical marks. Inter¬ 
nal storage of ASCII codes allows implicit 
collation of terms. Display of English text 
requires only upper- and lowercase letters 
to generate output comparable to printing 
generated by other means. 

By contrast, many non-English lan¬ 
guages use characters that increase the 
complexity of computerization. Lan¬ 
guages that use diacritical marks for cer¬ 
tain characters require different methods 
for input, storage, and display, often in¬ 
cluding modified or special keyboards, 
character codes, and display techniques. 
Collation is complex, requiring different 
rules for different languages or sometimes 
even for the same language; for example, a 
German telephone directory is collated 
slightly differently from a German dic¬ 
tionary. Standard character codes do not 
correspond to any of these collation rules. 
Some languages display special charac¬ 
ters for certain letter combinations, such 
as the use of (3 for the double “s” in German. 
Because many computer languages use 
English words and characters, countries 
with different alphabets (such as Greek 
and Cyrillic) must also use English charac¬ 
ters. (I use the term “English” to describe 
the alphabet in the ASCII character set, 


Since today’s 
bitmapped 
workstations support 
multiple character 
fonts, we can use X 
Windows, C, and 
MUMPS to display and 
manipulate multiple 
national character sets 
in a windows 
environment. 


without diacritical characters.) 

Some Middle Eastern languages also 
require special treatment for input and dis¬ 
play. Hebrew and Arabic, for example, are 
written from right to left, except for numer¬ 
ics, which retain left-to-right place value 
notation. In addition, some Arabic charac¬ 
ters have different shapes depending on 
their position in a word. 
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East Asian languages, particularly 
those based on the Chinese character set, 
offer additional complexities. Current 
East Asian character sets range from about 
7,000 characters to more than 33,000. 
International coordination between li¬ 
braries has led to a code system that accom¬ 
modates the principal character sets used 
in China, Japan, Korea, and Taiwan. 1 This 
character set uses three 7-bit bytes. Prob¬ 
lems of input, internal storage and colla¬ 
tion, and display also increase greatly with 
large character sets. 

Other languages also are displayed in 
unique ways. Korean alphabetic charac¬ 
ters are clustered in morphonemic syl¬ 
lables. The Devanagari script (used in 
Hindi and some other Indian languages) 
places vowels before, above, or below con¬ 
sonants with which they are associated. 

Most work on non-ASCII character sets 
has concentrated on improving input and 
display methods for a single non-English 
language. Internal manipulation and col¬ 
lation have received only limited atten¬ 
tion. Recently, however, researchers have 
begun to address the more general prob¬ 
lem of designing a true multilingual envi¬ 
ronment that can accommodate several 
character sets or languages. This article 
describes a workstation that supports 
many character sets in a windows environ¬ 
ment and provides display and data ma¬ 
nipulation of multiple character sets. 
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Previous work in 
multilingual support 

Research to date has involved four basic 
issues: character-set standardization, text 
input, internal storage and manipulation, 
and display systems. 

Standard character sets.* A number 
of national and international committees 
are working to standardize character sets. 
Although the ASCII character set is the 
most common internal code for computer 
representation of printed characters, 
many other standards exist. We can divide 
non-ASCII character sets into two broad 
groups: those that support a single lan¬ 
guage or subgroup of languages and those 
that attempt to support a significant num¬ 
ber of languages. 

One-byte national or subregional char¬ 
acter sets. We can also divide non-ASCII 
character sets into 1-byte (7- or 8-bit) 
codes and multibyte code sets. This sec¬ 
tion offers some important examples of the 
former. 

• European and Mediterranean charac¬ 
ter sets. The International Standards Or¬ 
ganization has proposed a series of 8-bit 
character sets to represent all European and 
Mediterranean languages as well as Afri¬ 
kaans. Included are four Latin script sets, 
ISO 8859-1, 8859-2, 8859-3, and 8859-4, 
which together cover Latin scripts from 
nearly all languages using Latin script. 
(The principal exception is Vietnamese, 
for which a separate 1-byte coded charac¬ 
ter set standard is being developed.) Also, 
ISO 8859-5 defines the Latin/Cyrillic al¬ 
phabet, ISO 8859-6 includes the Latin/ 
Arabic alphabet, ISO 8859-7 contains the 
Latin/Greek alphabet, and ISO 8859-8 
covers the Latin/Hebrew alphabet. A re¬ 
cent addition, ISO 8859-9, provides a 
more complete representation of Turkish 
characters. Some of these character sets 
differ from standards proposed by indi¬ 
vidual countries (such as Israel). Interna¬ 
tional efforts to bring these character sets 
into conformity are continuing. 

• Cyrillic. KOI-8 (also known as the 
GOST 19768-74) retains ASCII charac¬ 
ters for the first 127 character positions and 
includes the Cyrillic alphabet in the 8-bit 
extensions. This character set is being re- 


* Much of the information in this section is derived from 
the work of John Clews, 2 who offers the most complete 
review of international cnaracter sets I know of. 


Problems of input, 
internal storage and 
collation, and display 
increase greatly with large 
character sets. 


vised, and international standards groups 
are awaiting the outcome of these revisions 
before issuing new ISO character sets. The 
revision is planned to give the Cyrillic let¬ 
ters in Cyrillic code and to provide addi¬ 
tional non-Russian Cyrillic letters — nei¬ 
ther of which is provided in KOI-8. 

• Indian character sets. The most com¬ 
mon of the several scripts used in India is 
Devangari, which is used for Hindi, San¬ 
skrit, and several other Indian languages. 
Devangari has 33 consonants and 11 
vowels that are “attached” to the conso¬ 
nants in varying ways. 2 To accommodate 
additional script forms, India has adopted 
Pariwardhit Devangari, which incorpo¬ 
rates Devangari analogues for symbols 
used in other Indian languages. The Indian 
Standard Code for Information Inter¬ 
change is a de facto standard in India; three 
different versions have been released (in 
1983, 1986, and 1988), but none has been 
formally adopted as a national standard by 
the Indian Standards Institute. There are 
both 7-bit and 8-bit versions, the latter pre¬ 
serving the ASCII character set. 

Multibyte subregional character 
codes. To accommodate the vast number 
of characters needed for East Asian lan¬ 
guages, character codes intended for in¬ 
formation interchange (as opposed to 
internal codes) use two 7-bit bytes that 
define a plane with 94 positions on a side (a 
total of 8,836 possible characters). Binary 
values corresponding to ASCII control 
code positions (the first 33 positions) and 
the delete character (127) are reserved and 
are not used for graphic characters. 

• Japan. Japan produced the first 2-byte 
character set, JIS C 6226-1978, which was 
revised in 1983 and subsequently renamed 
JIS X 0208. This code consists of a 2-byte, 
14-bit code containing English, Russian, 
and Greek characters, the two phonetic 
Japanese alphabets (hiragana and 
katakana), and two groups of Chinese 


characters (called kanji in Japanese). The 
kanji characters are stored in two levels; 
Level 1 contains the 2,965 most commonly 
used characters, and Level 2 contains an 
additional 3,388 characters. Further 
planes containing additional kanji charac¬ 
ters are being considered. (Some groups, 
such as the National Diet Library and the 
nationwide National Center for Scientific 
Information Systems network, use an ex¬ 
tended version of the 1978 JIS code. Some 
observers state that surprisingly few users 
have adopted the 1983 revisions. 2 ) It is 
historically significant that this was the 
first approved national standard that in¬ 
cluded alphabets of several cultures. 

• People’s Republic of China. GB 2312- 
80 Coded Chinese Graphic Character Set 
is a 2-byte, 7-bit code containing 6,763 
simplified characters. The form of these 
characters differs slightly from the Japa¬ 
nese simplified characters described ear¬ 
lier. Also, although the overall structure of 
the code set is similar to the Japanese X 
0208 (and is identical in the positioning of 
many of the non-Chinese characters), the 
Chinese characters (called hanzi in Chi¬ 
nese) are placed in different positions. As 
in the Japanese standard, the hanzi charac¬ 
ters are arranged in two levels according to 
their frequency of use. Two further planes 
for even less frequently used hanzi charac¬ 
ters have been developed, for a total of 
three planes of simplified characters. In 
addition, three planes of traditional char¬ 
acters, with directly related coding, have 
also been produced. 2 

• Korea. The KS C 5601-1986 character 
set is the most recent standard revision 
approved for that language. The overall 
format follows the Japanese pattern, with 
16 rows for phonetic characters. How¬ 
ever, Cyrillic and Greek characters are not 
in the same positions as in JIS X 0208 and 
GB 2312-80. The remainder of the code is 
a 2-byte character code consisting of 2,350 
character clusters of compound hangul 
(phonetic Korean character clusters) and 
4,888 characters of hanja (Chinese) char¬ 
acters. 2 Some internal codes allow the 
Korean character cluster to comprise a 2- 
byte, 14-bit code that contains three parts: 
an initial consonant, a vowel, and a final 
consonant group. Display of the individ¬ 
ual phonemes varies depending on usage 
in a particular word. Because KS C 5601 
has government backing, it seems likely to 
replace the 1981 Korean Information 
Processing Standard (KIPS) and KS C 
5619-1982 2-byte character sets. 

• Taiwan. Taiwan uses two character 
codes, consisting of 2-byte planes of 
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Figure 1. The Maltron keyboard. Its ergonomic design solves many of the design 
problems of the Qwerty keyboard. 


94 X 94 characters. The first, developed 
by the Institute for Information Industry 
and published in 1986, is referred to as the 
General Chinese Character Standard 
Interchange Code 1 (also known as CNS- 
11643 2 ). This is a 7-bit, 2-byte code whose 
latest version contains 13,051 Chinese 
characters, 651 symbols, and 33 control 
characters contained in two planes. 

The second character set, called the 
Chinese Character Code for Information 
Interchange (CCCII) is an extension of the 
plane concept. It uses three 7-bit bytes that 
can be visualized as a cube consisting of 94 
planes, each containing 94 x 94 charac¬ 
ters (with control characters in the first 
plane) for a theoretical total of 830,584 
characters. Volume III of this coding 
scheme, published in 1987, encodes 
33,600 characters. 1 As discussed in the 
next section, this coding system is the ba¬ 
sis for a proposed universal character set. 

Proposals for standard universal char¬ 
acter sets. Three international groups are 
working separately on standardizing 
multilingual character sets. 2 The Ameri¬ 
can National Standards Institute (ANSI) 
has defined the East Asian Character Code 
(EACC), which is based on the CCCII 
character set just described. Two working 
groups of ISO technical committees are 
developing potentially conflicting stan¬ 
dards. Working Group No. 1 of Subcom¬ 
mittee 4 (Computer Applications in Infor¬ 
mation and Documentation) of ISO Tech¬ 
nical Committee 46 (Documentation) is 
considering EACC as a candidate for inter¬ 
national standardization, although no 
binding commitment has been made. 
Working Group No. 2 of Subcommittee 2 
(Character Sets and Information Coding) 
of Technical Committee 97 (Information 
Processing Systems) is responsible for 
developing a multibyte graphic character 
code. This group has been working on 8- 
bit, 4-byte character sets that differ sig¬ 
nificantly from those being considered by 
the first two groups. 

The EACC standard resulted from work 
by the Research Libraries Group to pro¬ 
vide Chinese, Japanese, and Korean char¬ 
acter set capabilities for library documen¬ 
tation. It has been adopted by the Library of 
Congress and the On-line Computer Li¬ 
brary Center and has also been adopted as 
an ANSI standard. The code uses the 
CCCII’s 94 x 94 planes as its structural 
model. It also arranges planes into levels, 
six planes to a level, to help group Chinese 
characters from different standards. Lev¬ 
els are also useful for portraying variant 


forms of the same Chinese character, since 
a given character might have several vari¬ 
ants, each with the same code value but in a 
different plane on the same level. 1 - 2 EACC 
incorporates four Asian character codes 
mentioned earlier: GB 2312 (People’s 
Republic of China), JIS C 6226 (Japan), 
KIPS (Korea), and the 1982 edition of 
CCCII. (EACC does not include all CCCII 
characters.) Once characters are assigned 
in EACC, they are not changed. The Li¬ 
brary of Congress maintains the registry of 
new characters for this standard. 

The second of the two ISO efforts men¬ 
tioned above seeks to place in one plane all 
existing ISO 8859 and other 1-byte na¬ 
tional standard character sets. This provi¬ 
sional standard has been assigned the 
number ISO DP 10646. Most current al¬ 
phabetic character sets (and all alphabetic 
scripts in official use at national or state 
levels) are incorporated in four alphabetic 
areas of the basic multilingual plane, 
which is a two-octet, 256 x 256 plane with 
space for approximately 36,000 characters 
(excluding areas for nongraphic charac¬ 
ters). 2 Three sets of East Asian characters 
(from the Chinese, Japanese, and Korean 
standards) are also included in this plane. 
The structure allows additional graphic 
characters to be assigned to other planes or 
groups. It is also theoretically possible to 
incorporate the EACC character set in¬ 


stead of each country’s individual stan¬ 
dards. As Clews notes, it is unfortunate 
that these standards bodies have not 
reached consensus on a plan to develop a 
single character code set. 2 

Input methodologies. For the most part, 
the design of today’s computers is based on 
the English language, so it is natural that 
processing English text is easier than pro¬ 
cessing text in other languages. In addi¬ 
tion, the English character set is simpler 
than that of most other languages except 
under special circumstances such as rep¬ 
resenting foreign words, equations, or 
special fonts. 

However, English input itself is ham¬ 
pered by the Qwerty keyboard. Despite its 
inefficient layout and positioning of keys, 
the Qwerty keyboard has survived as the 
principal means of input for English and 
other languages for over a century. A num¬ 
ber of other devices have been proposed, 
the Dvorak keyboard being the best 
known. The most promising recent design 
is the Maltron keyboard developed by 
Stephen Hobday and Lillian Malt (see Fig¬ 
ure l). 3 This design overcomes most of the 
Qwerty keyboard’s design flaws. It takes 
advantage of the dexterity of both thumbs 
by giving them control of a number of im¬ 
portant keys, including the letter “e,” 
space, period, and enter. The keys are sepa- 
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rated into two pods, one for each hand, and 
placed in a concave configuration that 
eliminates the need for users to move their 
hands to access all keys. These last two 
features reduce two known causes of se¬ 
vere strain resulting from Qwerty key¬ 
board use. The keys are also repositioned 
to increase alternate hand typing and to 
make greater use of the most dextrous fin¬ 
gers (giving a slight bias to the right hand). 
This keyboard can increase the speed of 
any user, even professional typists. 3 

Input problems in other languages are 
considerably more complex. The fre¬ 
quency of use of characters in foreign lan¬ 
guages is different from that in English. 
German, for example, makes little use of 
the letter “y” but frequent use of the letter 
“z,” so those two letters are transposed on 
German typewriters. 

Western European languages other 
than English generally use diacritical 
characters. Letters such as a and 6 in 
French, ii in German, 0 in Norwegian, and 
n in Spanish require special treatment for 
both input and display. It is technically 
possible but cumbersome to type the char¬ 
acters just cited using ASCII characters and 
a Qwerty keyboard. As a result, language- 
specific keyboard layouts have been adopt¬ 
ed that allow for the relative frequency of 
letter use in the different alphabets. 

Input problems are compounded in lan¬ 
guages that print from right to left, such as 
Arabic and Hebrew. When the default in¬ 
put mode is Arabic, some computers re¬ 
quire that English characters be input in 
reverse order. Becker describes a different 
method in which the keyboard is temporar¬ 
ily reconfigured for each alphabet, so the 
characters are accepted in the conven¬ 
tional mode for each language. A prompt 
window on the display indicates the cur¬ 
rent keyboard configuration. 4 The con¬ 
cept of a language-independent keyboard 
is an important contribution to multilin¬ 
gual processing. 

Input of Oriental languages poses even 
more difficult problems. The use of logo- 
graphic, rather than alphabetic, charac¬ 
ters to represent words stems from ancient 
Chinese writing, which was also adopted 
by the Japanese and Koreans around 1,000 
years ago. These symbols are effective in 
permitting communication between cul¬ 
tures that speak different dialects, but the 
large number of characters and their dif¬ 
ferent pronunciations in each language 
create serious input difficulties. 

Huang and Huang categorize input 
techniques as shown in Figure 2.' (I con¬ 
centrate here on the “touch” methods.) 


Despite its inefficient 
layout, the Qwerty 
keyboard has survived as 
the principal means of 
input for over a century. 


The ultimate speed of input depends on the 
number of keystrokes per character as well 
as ambiguities that might result when the 
input technique must select from two or 
more characters. Ease of learning is also an 
important measure of input effectiveness. 5 

Input methods based on the shape of 
Asian characters require large keyboards, 
are difficult to learn, and are slow even for 
trained professionals. Methods involving 
codes require memorizing either numeric 
codes or alphanumeric keys relating to 
shapes. Phonetic input methods lead to 
large numbers of homonyms, slowing the 
input process. 

One of the most promising techniques in 
both China and Japan involves phonetic 
input that is subsequently converted to the 
final characters using words or phrases 
rather than individual characters. (Most 
Chinese and Japanese words require more 
than a single character.) Current Japanese 
word processors use this technique. 
Becker describes the efficiency of one 
such approach for the input of Chinese 
text. He reports that typing a typical Chi¬ 
nese text in word-cluster mode required an 
average of 3.7 strokes per character using 
romanized phonetic input, and 2.7 using a 
more specialized phonetic technique (the 
Ju Yin method). 6 

Phonetic methods based on word and 
phrase clustering are also becoming the 
most widely used method for Chinese in¬ 
put. The latest versions of Chinese Charac¬ 
ter DOS provide extensive word- and 
phrase-clustering dictionaries based on 
the Mandarin dialect. For a user who 
speaks Mandarin, this input method is eas¬ 
ily learned and effective. However, there 
are many Chinese dialects, and even 
though the Chinese government requires 
instruction in Mandarin through elemen¬ 
tary school, individuals whose native dia¬ 
lect is not Mandarin might have difficulty 
with the Mandarin-based pinyin input 
method. In Hong Kong, for example, the 


Tsang-Chi method (called Cangjie in pin¬ 
yin) is preferred by many people whose 
native dialect is Cantonese. 7 

In Japan, the input problem is slightly 
different. Unlike Chinese, the Japanese 
language has two alphabets, each with 
approximately 50 syllables that usually 
consist of a consonant followed by a 
vowel. Diacritical marks are used, for ex¬ 
ample, to change the character “ha” to “pa” 
or “ba.” Pronunciation of kanji characters 
can be based on the old Chinese “on” pro¬ 
nunciation or the Japanese “kun” pronun¬ 
ciations. Ambiguities are usually re¬ 
solved by considering words, which usu¬ 
ally consist of two or more kanji charac¬ 
ters, or phrases, which further reduce 
ambiguity. Since Japanese text can be 
written based entirely on these phonetic 
alphabets, it is natural that word- and 
phrase-clustering methods are widely 
used in Japanese word processors. As a 
further convenience, Japanese familiar 
with the Qwerty keyboard can type these 
alphabets using romanized (romaji) input 
that displays the kana characters. Further 
speed improvements can be gained with 
specialized keyboards, such as the one 
developed by Morita that uses direct kana 
input. 8 However, Yamada concludes that 
the use of coded characters is preferable, at 
least for the skilled typists in his studies. 9 

Korean input uses a special layout of 
Korean phonetic characters on a standard 
Qwerty keyboard. If conventional Korean 
spelling is used, ambiguities in synonyms 
are resolved by the context of the sentence. 
If a user wishes to select Chinese logo- 
graphs (about 4,000 are in use in Korea for 
optional display of words), a menu ap¬ 
pears giving the different Chinese charac¬ 
ters represented by the Hangul spelling. 

The problem of providing a simple, effi¬ 
cient input method in a multilingual envi¬ 
ronment remains complex. Multiple input 
devices, including voice as well as key¬ 
boards, could be one solution. More re¬ 
search in this area is sorely needed. 

Internal character representation. 

The internal representation of characters 
requires different treatment in a multilin¬ 
gual environment than in monolingual 
text systems. If more than one character set 
is used, there must be a way to distinguish 
different code sets in mixed representa¬ 
tions. Also, compressing characters 
might be helpful, especially multibyte 
codes. Finally, collation order could be 
considered when storing certain types of 
texts (such as sorted lists of names). 

As noted earlier, most multilingual 
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Figure 2. Classification of Chinese input methods. Reproduced with permission. 1 


character codes allow use of the ASCII 
character set in addition to the other codes 
used. This provision prevents inadvertent 
interpretation of other codes as ASCII 
control characters, which might have 
unwanted effects on the operating system 
or other machine-dependent features. 
However, conflicts in code values other 
than ASCII are common. Conversion from 
one character set to another can be accom¬ 
plished by using the control characters SO 
(shift out) and SI (shift in) for 7-bit code 
extensions and by escape code sequences 
for more complex character shifts. ISO 
2022-1986 defines the manner in which 
these characters can be used, and ISO 2375 
provides the international registry of es¬ 
cape sequences assigned to different char¬ 
acter sets. 

Code compression is useful for internal 
storage where large data files are initially 
represented in multibyte character sets. 
Huang and Huang describe several com¬ 
pression techniques for the CCCII charac¬ 
ter set. 1 Lua describes a modified Huffman 
coding technique for Chinese characters 
based on the relative frequency of use. 10 
His study suggests that such a method can 
achieve an overall storage cost of 7.8 bits 
per character. 

The manner in which text-related ma¬ 
terials are processed also effects their inter¬ 
nal representation. Sorting is an important 
aspect of computer processing that can be 
simplified by devising coding schemes 
whose collation sequence matches appli¬ 
cations’ sorting needs. Unfortunately, 
collation is a complex issue. Different lan¬ 
guages using the Latin alphabet have sig¬ 
nificantly different collation rules. In East 
Asian countries, collation may be based on 
alphabetization or on the use of basic com¬ 
ponents (radicals) in a logographic char¬ 
acter combined with the number of pen 
strokes required to write the character. 

ASCII code values permit reasonably 
effective (but not perfect) collation of 
English text because the code values of the 
characters correspond to English colla¬ 
tion conventions. However, the ASCII 
collation sequence does not work when 
uppercase and lowercase letters are 
mixed. For example, an ASCII-based in¬ 
dex of computer terms would store all 
uppercase words before any lowercase 
words — placing “CMOS” before “ca¬ 
nonic” — unless bit 6 is ignored. 

Non-English Latin alphabet collation is 
much more complex. ISO 8859 codes 
place all characters with diacritical marks 
well beyond the code values of unaccented 
characters. Collation rules in European 


languages differ from one nation to an¬ 
other and, in some cases, even within the 
same country. 

The Chinese GB 2312-80 assigns char¬ 
acter codes of Level 1 characters accord¬ 
ing to the hanyu pinyin spelling conven¬ 
tion for the 3,755 words on that level. The 
second group of 3,008 characters is stored 
according to radical and stroke count. Col¬ 
lating the entire character set would re¬ 
quire extensive processing. Furthermore, 
a single collation methodology is insuffi¬ 
cient for many applications. For example, 
the Chinese-language telephone direc¬ 
tory in Hong Kong contains names sorted 
according to radical and stroke count, but 
it also has two indexes, one based on Man¬ 
darin and the other on Cantonese pronun¬ 
ciation. 

There are three basic forms of Japanese 
dictionary: alphabetic according to the 
Japanese alphabet, alphabetic according 
to the Latin alphabet, and sorted based on 
radicals and stroke counts. Most current 
Japanese dictionaries are sorted accord¬ 


ing to the kana alphabet, using a roughly 
5x9 matrix of characters beginning with 
the vowels a, i, u, e, and o, with subsequent 
lines appending the vowels to the letters k 
(ka, ki, ku, etc.), s, t, n, h, m, y, r, and w. 
Some of these characters can be modified 
by diacritical marks, subscripted vowels, 
or double consonants. There are several 
different kana collation rules adopted by 
different Japanese dictionaries. 

Standards bodies have to some extent 
addressed character-set treatment of col¬ 
lation sequences, but the problem remains 
largely ignored in high-level languages. 
Important work in this area is being done 
by the ANSI and ISO standards groups 
dealing with the structured query lan¬ 
guage (SQL) relational database stan¬ 
dard. 11 I present a new proposal for treating 
this problem later in the article. 

Display. Display options for English 
text include font, character size, and spe¬ 
cial attributes (bold, underline, sub- or 
superscript, spacing, reverse video, etc.). 
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Bitmapped workstations allow wide lati¬ 
tude in these areas, and their capabilities 
have been extended to other character sets, 
making it possible to use special fonts for 
most national character sets. Fonts for 
Latin characters have improved to the 
point that they compare favorably with 
typeset text. 

The display of Oriental characters pre¬ 
sents more difficulty. Chinese characters 
are much more complex than those of the 
Latin alphabet and require more sophisti¬ 
cated display techniques. Furthermore, 
Oriental cultures place a higher value on 
the rendition of these characters, since an 
important part of their education involves 
learning how to make well-formed, pleas¬ 
ing characters. According to Huang and 
Huang, dot-matrix techniques using a 
16 x 16 matrix cannot produce characters 
of acceptable quality, 1 but storage of the 
more acceptable 24 x 24 dot-matrix char¬ 
acters requires additional memory. Vec¬ 
tor generation of characters, which can 
produce more effective output, requires 
more internal storage and slows display 
speed. Despite these difficulties, bitmap¬ 
ped workstation fonts are improving 
steadily, and current display technology 
for screens and printers is reaching a satis¬ 
factory level. 

One factor in the display of Oriental 
characters has been largely ignored. As 
discussed earlier, input techniques fre¬ 
quently involve phonetic input followed 
by conversion to the nonalphabetic Chi¬ 
nese characters. For Japanese, which usu¬ 
ally has several alternative pronunciations 
for a kanji character. Oriental word pro¬ 
cessors do not retrieve the correct pronun¬ 
ciation for a character in a given context. 

There are two reasons to retain phonetic 
representation wherever possible. The 
first relates to collation of the characters 
which, as noted earlier, is frequently based 
on phonetic pronunciation. The second 
reason relates to the difficulty Westerners 
have in reading Chinese characters. West¬ 
erners would probably use East Asian lan¬ 
guages more widely if alternate display 
forms were available, such as the presenta¬ 
tion of Japanese kana instead of, or in con¬ 
junction with, the Chinese characters. 
Making phonetic information about Chi¬ 
nese characters available could resolve 
both of these issues. 

Few systems offer multilingual capa¬ 
bilities for both alphabetic and nonalpha¬ 
betic scripts. The Xerox Star is one such 
system, 4 - 6 but it is not widely, used and 
might not be commercially supported in 
the future. Several companies are working 


Chinese characters are 
more complex than those 
of the Latin alphabet and 
require sophisticated 
display techniques. 


on multilingual systems, but none have 
made product announcements. 

Design of a 

multilingual 

workstation 

Figure 3 outlines the overall design con¬ 
siderations associated with a multilingual 
workstation. The environment must pro¬ 
vide for input, internal manipulation and 
storage, and simultaneous display of mul¬ 
tiple languages. Ideally, such a system 
should accommodate multiple input tech¬ 
niques and store multiple character sets in 
separate or mixed modes. Displays should 
output multiple fonts in a single window. 
Translation between different character 
sets and string processing of multiple 
character sets is also required. The system 
should provide user-modifiable default 
environments, suitable for different lan¬ 
guages, that can be invoked simultane¬ 
ously for different windows. 

Specifically, the necessary features of 
such a workstation include the following. 

• The workstation should provide na¬ 
tional character set environments. The 
defaults should include definition of char¬ 
acter set; assignment of appropriate input 
hardware and software; specification of 
storage method, including collation; in¬ 
ternal string manipulation; and definition 
of default display method. 

• In addition to the defaults, alternate 
mechanisms for each function must be 
available. It should also be possible to as¬ 
sign these functions permanently to given 
devices and variables. 

• It should be possible to display more 
than one national character set environ¬ 
ment on a single output device. 

• A given window must be able to dis¬ 
play multiple national character sets si¬ 
multaneously. 


Although these goals sound ambitious, 
they are attainable with current technol¬ 
ogy. Today’s workstations offer wide 
ranges of input and display capabilities. 
Appropriate conversion programs for Ori¬ 
ental characters are already on the market. 
Internal manipulation and storage of mul¬ 
tiple character sets can be achieved in a va¬ 
riety of ways. What remains is to put these 
pieces together in a coherent framework. 

A multilingual workstation based on 
X Windows, C, and MUMPS. The system 
proposed here uses an emerging standard 
display environment and two ANSI stan¬ 
dard high-level languages, that is, X Win¬ 
dow System, C, and ANSI XI 1.1 1984 
(otherwise known as the Massachusetts 
General Hospital’s General Multipro¬ 
gramming System, or MUMPS). To¬ 
gether, these components offer a solid 
foundation for supporting multilingual 
workstations. 

Operating system support. This envi¬ 
ronment currently runs on Unix-based 
workstations using X Windows Version 
11. This emerging standard is available on 
many different workstations, increasing 
portability while allowing for high-speed, 
vendor-specific alternatives. Under X 
Windows, users can create independent 
windows, invoke special fonts, and use 
cursor control to move between windows. 
They can also invoke these functions from 
programs running within the X Windows 
environment to create satellite windows. 
A large range of fonts (many of them pub¬ 
lic domain) are available, and several Ori¬ 
ental character sets have been added re¬ 
cently. Multiple fonts can be invoked in 
the same window. Finally, programs can 
be invoked under X Windows to accom¬ 
plish the remaining functions not ad¬ 
dressed by the environment itself. Such 
abilities might be available from other 
proprietary systems, but the widespread 
availability of this environment makes it 
an ideal vehicle for this research. 

A national character set (NCS) environ¬ 
ment. Researchers at UC Davis have created 
an applications development environ¬ 
ment that supports multiple programming 
languages communicating transparently 
with each other in a window system. 12 C, 
MUMPS, and other high-level languages 
now operate in this environment, 13 so each 
language can be used for those tasks for 
which it is best suited. In this case, C in¬ 
vokes Window commands, and MUMPS 
controls the NCS environment. 
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Figure 3. Functional components of multilingual support. 


Several features of MUMPS make it an 
ideal candidate for NCS support. Its pow¬ 
erful string-handling features have been 
extended to support both Japanese and 
Chinese character sets (although these 
extensions do not run concurrently). Its 
imbedded shared data facility permits the 
use of keys (subscripts), including text 
strings that collate according to the char¬ 
acter set in use (usually ASCII). In addi¬ 
tion, its evolution is controlled by an inter¬ 
national group committed to using current 
and extended functions to achieve the 
“internationalization” described here. 
MUMPS proponents hope to secure ISO 
approval for the language soon. 

The NCS environment comprises sev¬ 
eral approved MUMPS functions plus a 
limited number of syntactically coherent 
extensions. Provisionally approved 
“structured system variables” can be used 
to define characteristics of various de¬ 
vices (input, internal storage, character 
manipulation, and display). Thus, a user 
can specify and invoke an NCS’s default 
environment for a given window. I have 
proposed a syntax to define the structured 
system variables needed to achieve this 
objective. By maintaining several stan¬ 
dard sets of defaults, different NCS envi¬ 
ronments can be invoked and executed 
simultaneously in independent windows. 
NCS also defines a syntax to permit chang¬ 
ing these defaults. 

I have also proposed a new syntax for 
overriding default specifications. The 
general format consists of preceding cer¬ 
tain commands with the NCS specifica¬ 
tion enclosed in braces. This syntax, 
which is now being tested in the multilin¬ 
gual environment, is compatible with the 
current standard and syntactically consis¬ 
tent in its various forms. 

Input. Many language-specific input 
and conversion techniques are available. 
Unfortunately, most of these systems in¬ 
volve modifications to the underlying 
operating system and are incompatible 
with each other. However, a number of 
researchers are investigating multilin¬ 
gual input methodologies. For this reason, 
my research has concentrated on other 
aspects of the multilingual problem. 

Storage and collation. MUMPS func¬ 
tions such as STRANSLATE and 
SORDER facilitate internal storage and 
manipulation of ASCII characters. Use of 
the ISO 2022 escape sequences permits 
extending these features to other character 
sets within accepted international stan¬ 


dards. It is also possible, using the same 
approach, to create new internal codes that 
serve additional functions. For example, 
by using translation tables, ASCII charac¬ 
ters can be stored to provide correct mixed 
upper- and lowercase collation. The same 
ability can provide alternate collations for 
other character sets. A single MUMPS ar¬ 
ray (equivalent to a file in most data sys¬ 
tems) would be restricted to a single colla¬ 
tion sequence associated with its name, 
but multiple variables with different col¬ 
lation algorithms could be stored in a 
single system. Multilingual files could 
similarly be shared in this environment, 
along with message files permitting com¬ 
munication between, windows. 


Internal manipulation. MUMPS’ 
string-handling features have already 
been modified in the Japanese and Chinese 
versions to extend functions such as 
SLENGTH, SPIECE, SEXTRACT, and 
the Contains, Follows, and Pattern-match 
operators. By using structured system 
variables, these modifications could be 
stored in tables and invoked for each NCS 
environment. Mixed-mode strings would 
be correctly treated by including escape 
sequence identifiers. The collation func¬ 
tion, SORDER, would rely on the manner 
in which data are stored, and translation 
tables would convert internal codes prior 
to their interpretation as characters. The 
tools are therefore available for auto- 
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Figure 4. Mock-up of a multilingual display environment. Separate independent 
English, Japanese, and Chinese windows collate terms according to national col¬ 
lation rules for each language. Multiple fonts can be displayed in any window us¬ 
ing default overrides. 


mated character-set conversion and ulti¬ 
mately for automated natural-language 
translation. 

Display. C functions combined with X 
Windows fonts currently provide the 
mechanism for displaying different fonts. 
Although MUMPS syntax exists to invoke 
device-specific features (such as Graph¬ 
ics Kernel Standard graphics), external 
calls to C provide the most effective display 
approach in the X Windows environment. 

Optional display of Japanese kanji in its 
hiragana form is supported through the 
methods used for internal storage of the 
characters. By providing a table that 
points to both the kanji character and the 
contextually appropriate hiragana repre¬ 
sentation, the workstation lets the user 
present the information in either form (or, 
by converting kana, in the Latin alphabet). 

Output to hard-copy devices is handled 
by either screen dumps or conventional 
laser printer software. Although high- 
quality text generation for Oriental char¬ 
acters is not widely available in Western 
countries, the situation is improving 
steadily. 

Summary of required extensions. At the 
operating-system level, we must consider 
how to coordinate several different lan¬ 
guage-specific approaches to non-ASCII 
support. Execution speed within such an 
environment might be compromised by 
providing multilingual support at a higher 
level in the operating system; however, the 
incompatibilities resulting from low- 
level solutions could prove insurmount¬ 
able when several other character sets 
must be accommodated. For research and 
demonstration purposes, a higher level 
approach is preferable. 

Desired improvements within X Win¬ 
dows include access to more fonts and 
greater support for non-ASCII input meth¬ 
ods. For some applications, interprocess 
communication between windows could 
benefit from further research. 

The MUMPS language standard should 
permit definition of an NCS environment, 
providing default and override capabili¬ 
ties controlling input, storage, process¬ 
ing, and display. The MUMPS Develop¬ 
ment Committee is considering ways to 
make these changes. 

Although this system can communicate 
transparently between C, MUMPS, and 
other programming languages, its overall 
performance could be improved. The abil¬ 
ity to achieve the desired objectives exists. 
The environment is flexible enough to ac¬ 


commodate the MUMPS Development 
Committee’s final specification of exter¬ 
nal calls, based on current trends in that 
standardization process. 


T his project has been active since 
1987, but many of the chief com¬ 
ponents required for a complete 
multilingual system are just now becom¬ 
ing available. 

A number of workstation vendors now 
provide operating-systems support for 
European and Oriental character sets. 
Many have special keyboards designed 
for different languages, Latin-to-Chinese 
character conversion, and screen and 
hardcopy output of non-ASCII charac¬ 
ters. My own laboratory has machines 
from several vendors available for devel¬ 
opment. Using these systems, we can gen¬ 
erate files of non-ASCII characters for 
manipulation in other components of the 
project. 

Access to foreign character set fonts is 
derived in part from the X Windows library 
and in part from other fonts developed pri¬ 
vately or by research institutions such as 
the Institute for System Science of the 
National University of Singapore. 

MUMPS has been partially modified, 
and the interface to X Windows and a trans¬ 
parent interface to other high-level lan¬ 
guages is operational. MUMPS-based 
display of multiple fonts is also opera¬ 


tional. For several years I have distributed 
separate PC-based versions of MUMPS 
that support Japanese and Chinese. These 
capabilities are being reproduced in the 
Unix version required for this research. 
Changes in the handling of standard char¬ 
acters have already been made in the per¬ 
sonal computer versions of MUMPS. 

The NCS environment and collation 
features discussed above are now being 
incorporated. Initial emphasis will be on a 
Japanese version, to be followed by Chi¬ 
nese and Spanish versions. Students 
fluent in each of these languages are active 
in the project. A prototype supporting at 
least three languages is anticipated within 
a year. 

I intend to apply this system in two proj¬ 
ects. The first will support an international 
medical project referred to as the Universal 
Medical Information Service. 14 The sys¬ 
tem will display medical dictionaries as 
illustrated in Figure 4, providing a basis for 
international epidemiological research. 

The second project involves using the 
system to teach foreign languages. The 
first expected use will be to teach Japanese 
to technical professionals (especially 
computer scientists). I will base the design 
on my own continuing experiences in 
learning the language, working in con¬ 
junction with native speakers, linguists, 
and instructors to develop a more effective 
learning environment than is currently 
available. ■ 
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Linda Meets Unix 


Wm Leler, Cogent Research, Inc. 


A s microprocessors become more 
and more powerful, it becomes 
increasingly possible to build 
inexpensive multiple processor machines 
with far greater computational power than 
the fastest traditional supercomputers. 
Although such hardware is relatively easy 
to build, it has a well-earned reputation for 
being difficult to program. Many of the 
problems associated with programming 
multiprocessor computers are due to the 
use of inappropriate parallel programming 
models that were developed for vastly dif¬ 
ferent purposes. To realize the promise of 
parallel computing, innovative new tools 
are required that will make these new 
parallel computers significantly easier to 
program. 

The models of parallel computing in 
common use today are largely inherited 
from operating systems. Operating sys¬ 
tems have long supported concurrent 
execution of processes through multi¬ 
programming, which is really pseudo par¬ 
allelism because multiple processes take 
turns executing rather than actually run¬ 
ning in parallel. With multiple processor 
machines becoming the norm rather than 
the exception, operating systems are be¬ 
ginning to support multiprocessing (true 
parallelism). Unfortunately, these two 
forms of parallelism are fundamentally 
different from each other. Multiprogram¬ 
ming allows several independent programs 
or users to share a single processor, while 
multiprocessing allows a single program 
to use multiple processors. Put another 
way, multiprogramming increases hard¬ 
ware utilization, possibly at the expense of 
execution speed of individual programs, 
while multiprocessing increases the exe- 


A system-level version 
of the Linda high-level 
parallel software 
paradigm is used as the 
basis of the QIX 
operating system, 
which supports both 
multiprocessing and 
multiprogramming 
while retaining Unix 
compatibility. 


cution speed of individual programs. 

As the mechanisms originally devel¬ 
oped to support pseudo parallelism are 
pressed into service to support true paral¬ 
lelism, their limitations are becoming more 
and more apparent. For example, even 
though both forms of parallelism incorpo¬ 
rate the concept of a process, the “heavy¬ 
weight,” application-oriented form of 
process developed during the days of 
multiprogramming is largely unsuitable 
for multiprocessing because process crea¬ 
tion is too complicated and expensive. 

The shift from pseudo parallelism to 
true parallelism involves taking the mul¬ 
tiple processes of a multiprogramming 
system and running them on the separate 
processors of a multiprocessing system. 


This form of parallelism is commonly 
called multiple-instruction, multiple-data 
parallelism. MIMD computers generally 
fall into two categories: 

• shared memory, and 

• distributed memory. 

This article discusses the limitations of 
the shared-memory and distributed-mem¬ 
ory models for explicit parallel program¬ 
ming and examines a new model, Scien¬ 
tific Computing Associates’ Linda parallel 
communication paradigm, which was de¬ 
signed specifically for parallel program¬ 
ming. 1 Then, this new model is adapted for 
use as the basis of a new class of operating 
system, and a specific instance, QIX, is 
presented. Like Linda, this new operating 
system model can support both the shared- 
memory and the distributed-memory 
styles of programming. Thus, it provides 
the benefits of both, while avoiding hard¬ 
ware dependencies. In addition, this new 
model provides benefits beyond those of 
either model and even those of Linda. For 
example, QIX incorporates a novel scheme 
for name resolution that is easier to use 
than other methods and provides signifi¬ 
cant benefits in the operating system. QIX 
also directly supports communication 
between programs written in different 
languages. 

Current parallel 
programming models 

To support multiprogramming, the fol¬ 
lowing facilities were added to operating 
systems: 
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Figure 1. Updating an unprotected shared variable. 


• interprocess communication, 

• process synchronization, 

• protection of shared resources, and 

• interprocess name resolution. 

Even though these facilities were origi¬ 
nally developed to support multiprogram¬ 
ming, they have been adapted to try to fit 
the needs of explicit multiprocessing. 

In existing operating systems, the above 
facilities are typically provided in one of 
two forms: the shared-memory model and 
the distributed-memory model. 

In the shared-memory model, separate 
processes are allowed to share address 
space. Processes communicate by access¬ 
ing and modifying shared data structures. 
Other mechanisms, such as semaphores, 
must be provided for synchronization and 
protection. Name resolution is typically 
performed statically, for example, at com¬ 
pile time by a link editor. 

In the distributed-memory model, the 
processes do not share address space, and 
message passing is used for communica¬ 
tion and synchronization. Access to shared 
resources is controlled through the use of 
server processes, which provide specific 
services to other processes. For example, 
name resolution is often provided by a 
name server. 

Lauer and Needham 2 were the first to 
classify operating systems into these two 
models, calling them procedure-oriented 
and message-oriented systems. They also 
showed that these two models are duals of 
each other, in that any program (including 
an operating system) written using one 
model can be written as an equivalent 
program using the other model. They con¬ 
cluded that the choice of which model to 
use should be based mainly on the facilities 
(such as hardware facilities) on which the 
program is built. Given Lauer and 


Needham’s conclusions, it is not surpris¬ 
ing that shared-memory computers typi¬ 
cally use shared-memory-model (proce¬ 
dure-call) operating systems and distrib¬ 
uted-memory computers typically use dis¬ 
tributed-memory-model (message-pass¬ 
ing) operating systems. 

In traditional multiprogramming, 
whether an operating system is based on 
the shared-memory or distributed-memory 
model has little effect on an applications 
programmer, since multiple processes are 
rarely used in a single application. Mul¬ 
tiple processes are used only to run sepa¬ 
rate applications concurrently, and what¬ 
ever small amounts of interaction there 
might be between applications can be 
handled using mechanisms such as pipes. 

For explicit parallelism, however, the 
choice of model directly affects the appli¬ 
cations programmer, because the operat¬ 
ing system mechanisms that support com¬ 
munication, synchronization, protection, 
and naming are the ones used to write 
parallel programs. This means that when 
parallel computers are used for explicit 
parallelism, the difference between 
shared-memory and distributed-memory 
hardware is directly exposed to applica¬ 
tions programmers. 

To exploit parallelism in a single pro¬ 
gram, the programmer is forced to use a 
hardware-specific programming model 
and associated low-level mechanisms. 
This is analogous to programming using 
assembly language and has the same 
disadvantages: parallel programs are dif¬ 
ficult to write because the programmer 
must deal with hardware details, and the 
resulting programs are not portable to 
other parallel (or even sequential) systems. 
The end result is that most parallel com¬ 
puters sold today are rarely used to write 
true parallel programs. 


Shared-memory model. In this model, 
processes communicate via shared mem¬ 
ory using normal memory read-and-write 
instructions. The familiarity of memory 
operations makes shared memory appear 
easy to use, but, unless other mechanisms 
are provided for synchronization and pro¬ 
tection, the resulting programs can suffer 
from unwanted nondeterminism such as 
race conditions. Figure 1 shows an ex¬ 
ample of a race condition where the shared 
variable x is incremented three times but its 
value only increases by two because the 
third process read the old value of x before 
the second process wrote its updated value. 

In systems built using a shared-memory 
model, mechanisms such as busy waits, 
semaphores, or monitors are typically used 
for protection and synchronization. For 
example, the variable x can be protected by 
use of a counting semaphore. Any process 
wanting to access x must first wait on the 
semaphore and then signal the semaphore 
when it is done. If another process tries to 
access x while the semaphore is locked, it 
will wait. The semaphore must be initial¬ 
ized before it can be used; the C++ code for 
this might look like: 

// the shared variable 

// semaphore for x 
semaphore x_sem; 

// initialize the semaphore 
signal(x_sem); 

The following code is then used to modify 


// wait until x is not in use 
wait(x_sem); 
x = x+ 1; 

// free x 
signal(x_sem); 

Similar code can be used to decrement 
or otherwise modify x. Unfortunately, the 
need for synchronization is easily over¬ 
looked, especially when parallelizing 
existing programs. It is all too easy to put 
in a little protection and assume the pro¬ 
gram is correct if it runs properly a few 
times, just to have it fail sometime later. 
So, while programs may be relatively easy 
to write using the shared-memory model, 
getting them to run correctly or assuring 
that they will continue to run correctly can 
be difficult. 

A further problem with mechanisms 
such as semaphores is the tendency to 
sequentialize a program. For example, 
consider a set of processes that spend most 
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of their time accessing a large shared data 
structure. If the entire structure is pro¬ 
tected by a single semaphore, only one 
process can run at a time, causing execu¬ 
tion of the processes to be sequentialized. 
Indeed, the overhead from using a sema¬ 
phore will often cause this program to run 
slower on multiple processors than an 
equivalent program on a single processor. 
A common solution to this problem is to 
use multiple semaphores to protect subar¬ 
eas of the data structure; however, finding 
the correct granularity can be difficult. 

In the shared-memory model, processes 
use shared address space for communica¬ 
tion and a mechanism such as semaphores 
for synchronization and protection, but 
some other mechanism is needed to re¬ 
solve names between separate processes. 
For example, in the semaphore program, 
separate processes must be able to access 
the same memory locations for the shared 
names x and x_sem. 

Many parallel programming systems 
avoid adding a new naming mechanism by 
using the program linker to resolve shared 
names. (Sometimes this is handled by a 
separate utility — a configurer — but it is 
still performed at link time.) Static (link 
time) name resolution severely restricts 
parallel programs. For example, if commu¬ 
nication paths are statically specified, then 
programs must be relinked when the num¬ 
ber of processors or the communication 
topology changes. Static linking also 
means that all parts of a program that need 
to communicate must be linked at the same 
time. In some cases, such as communica¬ 
tion between a user program and the oper¬ 
ating system, this is problematic. Some 
parallel computers, especially those used 
as attached processors on a host, solve this 
problem by linking each application with 
the entire operating system (in this case the 
operating system is usually called a run¬ 
time system and the computer is typically 
rebooted for each application). Other sys¬ 
tems use mechanisms such as jump tables 
or provide some form of dynamic (run¬ 
time) name service. 

Distributed-memory model. The dis¬ 
tributed-memory model uses message 
passing for communication and synchroni¬ 
zation. Messages are sent to a specific 
message channel and received by waiting 
on that channel. There are many variations 
on this, for example, whether the sender 
blocks until the message is received (syn¬ 
chronous send) or not (asynchronous 
send), or how many senders and receivers 
are allowed to use the same channel. An- 
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other variation relates to how channels 
are specified. In many systems, a mes¬ 
sage is sent to a specific process on a 
specific processor (consequently, such a 
system can only have a single receiver 
per channel). 

Shared resources (like the variable x in 
Figure 1) are protected by enclosing them 
inside a process that has sole access to the 
resource. Such a process is called a server 
process. Here, for example, is a process 
that receives messages to increment or 
decrement x. 

x_process(channel chan_id) 

{ 

int x = 0; 

// loop forever receiving messages 
while(TRUE) { 
message msg; 
receive (chan_id, msg); 
switch (msg) { 
case INCREMENT: 
x = x+ 1; 
break; 

case DECREMENT: 
x = x- 1; 

default: 

return; 


} 

} 


Other processes must send a message to 
this process to increment the value of x: 

message msg = INCREMENT; 
send (chan_id, msg); // increment x 

The variable x is protected from simultane¬ 
ous access because the x_process can only 
receive and process a single message at a 
time. But, the added complexity and over¬ 
head of having to encapsulate each shared 
resource in its own separate process pays 
for this safety. In addition, the process that 
protects a shared resource must anticipate 


every possible use of its resource. For 
example, in the above program there is no 
method of examining the value of the 
variable x or of modifying x by setting it to 
a specific value. 

In the distributed-memory model, pro¬ 
cesses use message passing for communi¬ 
cation and synchronization, and server 
processes for protection of shared re¬ 
sources. But, a mechanism is still needed 
to resolve names between separate pro¬ 
cesses. For example, in the message¬ 
passing program, a process wanting to 
increment the value of x must know the 
chan jd for the x_process in order to send 
a message to it. The most common way to 
do this is to provide a name server process. 

A typical name service is provided by 
Berkeley Unix 4.3 to allow the socket 
mechanism to resolve names across a net¬ 
work. For example, to connect to the whois 
service on a remote processor, the follow¬ 
ing code could be used (error checking has 
been omitted for clarity): 

// get the host entry for the 
// remote machine named george 
hostent *hp = 
gethostbyname(“george”); 

// get service entry for whois 
// service using tcp protocol 
servant *serv = 

getservbyname(“whois”, “tcp”); 

// create a socket 

int sock = socket (hp->h_addrtype, 
SOCK_STREAM, 0); 

// connect to the remote service 
sockaddr_in sa; 

bcopy((char*)hp->h_addr, (char*) 
sa.sin_addr, hp->h_length); 
sa.sin_family = hp->h_addrtype; 
sa.sin_port = serv->s_port; 
connect(sock, sa, sizeof(sa)); 

// at this point, sock is a socket that 
// can communicate with 
// the remote service. 

The code to use this name service has been 
shown mainly to demonstrate how obscure 
it is. Not surprisingly, only the bravest 
programmers use Unix for writing parallel 
programs. This problem is not restricted to 
Unix; other name services are often just as 
bad, and add considerable complexity to 
parallel programs. 

Choosing a model. Neither the shared- 
memory nor distributed-memory model is 
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clearly superior. In general, the shared- 
memory model is somewhat easier to pro¬ 
gram, but the resulting programs are more 
likely to contain unwanted nondetermin¬ 
ism, while the distributed-memory model 
is harder to program but more likely to run 
correctly. Some programs are easier to 
write using one model rather than the other, 
depending on factors such as the amount of 
communication and how much data can be 
treated as read-only. However, regardless 
of the model used, writing programs for 
parallel machines is traditionally much 
harder than writing programs for sequen¬ 
tial machines. 

When operating systems based on either 
the shared-memory or distributed-memory 
models are used for parallel programming, 
the choice of which model to use has been 
effectively taken away from the applica¬ 
tion programmer because the operating 
system supplies the primitives used for 
writing true parallel programs, and these 
generally mirror the underlying hardware. 
This means that a program written for one 
parallel machine is not easily portable to 
another, so the large investment spent 
writing a parallel program is generally lost 
when a different machine is purchased. 

Linda 

Linda is a parallel communication 
mechanism developed by David Gelemter 
at Yale University. 3 Rather than communi¬ 
cating with messages or through shared 
memory locations, processes communi¬ 
cate in Linda via a shared data space called 
tuple space. Tuple space acts something 
like an associative memory, since tuples 
are identified by matching on a key rather 
than using a specific address. There are 
four fundamental operations on tuple 
space: 

out place a tuple in tuple space 

in match a tuple and remove it 
from tuple space 

rd match a tuple and return a copy 
of it 

eval create an active tuple (a new 
process) 

A tuple is an ordered collection of data 
items. For example, the tuple 

(“hello”, 42,3.14) 

contains three data items: a string, an inte¬ 
ger, and a float. The operation 

out(“hello”, 42, 3.14); 



Figure 2. Message passing using Linda. 


places this tuple into tuple space. The out 
operation never blocks, and there can be 
any number of copies of the same tuple in 
tuple space. 

Tuples in tuple space are accessed by 
matching against a template. For example, 
the operation 

int i; float f; 

in(“hello”, ?i, ?f); 

will match any tuple in tuple space with 
three fields whose first field is the string 
“hello,” and whose second and third fields 
are an integer and a float, respectively. In 
this case, the string “hello” is the key used 
to find the matching tuple. If a matching 
tuple is found, the variables i and / are 
assigned the corresponding values from 
the matching tuple, and the tuple is re¬ 
moved from tuple space. If no matching 
tuple is found, the current process blocks. 
If the template matches more than one 
tuple, an arbitrary one is picked. The rd 
operation is like in, except that the matched 
tuple is not removed from tuple space. 

The eval operation resembles out, ex¬ 
cept that it creates an active tuple. For 
example, if fen is a function, then 

eval(“hello”, fcn(z), true); 

creates a new process to evaluate fen, 
which proceeds concurrently with the 
process that made the eval call. When the 
new process completes, it leaves the result¬ 
ing passive data tuple in tuple space, just 
like an out operation. 

Linda is a high-level tool for parallel 
programming in that it is not directly based 
or dependent on a specific hardware 
mechanism. As with any higher level tool, 
there will always be some overhead associ¬ 


ated with Linda, but it is not excessive (see 
the sections entitled “Implementing 
Linda” and “Kernel Linda”). This is simi¬ 
lar to higher level languages compared 
with assembly languages, where any over¬ 
head is usually outweighed by the benefits 
of easier programming and portability. 
Likewise, the flexibility of Linda can more 
than make up for any overhead. For ex¬ 
ample, dynamic load balancing, where the 
processing load is dynamically adjusted 
between multiple processors, is rarely used 
in parallel programs because it is difficult 
to implement using message passing or 
semaphores, despite its potential perfor¬ 
mance improvement; but it is relatively 
easy to implement using Linda (an ex¬ 
ample of dynamic load balancing is given 
in a later section). Linda also makes it easy 
to experiment with the parallel structure of 
a program to increase its performance. 

Using Linda like a shared-memory 
model. Linda can be used to model shared 
memory, but with the advantage that it is 
easy to avoid unwanted nondeterminism. 
In the example above, where the shared 
variable x was incremented by multiple 
processes, a semaphore was used to protect 
the shared variable from simultaneous 
access. Using Linda, we can represent a 
shared variable x as a single tuple whose 
key is the name x (we assume that no one 
else is using rasa key); to increment the 
variable x in tuple space, the following op¬ 
erations would be used: 

in(“x”, ?i); 

out(“x”, i+1); 

Since the in operation removes the match¬ 
ing tuple from tuple space, any other pro¬ 
cess trying to access the value of x will 
block until the tuple is put back by the out 
operation. 

Using tuple space as a shared data space 
is not limited to systems with shared 
memory; it will also work with distributed- 
memory computers. This makes programs 
written in Linda portable between shared- 
memory and distributed-memory systems. 

Using Linda like a distributed-mem¬ 
ory model. Linda can also support the 
message-passing style of programming. In 
Figure 2, a message is sent using an out 
operation and received using an in opera¬ 
tion. 

If the receiver gets ahead of the sender, 
it will block waiting on the next message. 
The sender is allowed to run faster than the 
receiver because the out operation is asyn- 
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chronous (it never blocks). As in any asyn¬ 
chronous message-sending situation, if the 
sender can get significantly ahead of the 
receiver, some sort of flow control must be 
used to avoid overflowing processor 
memory (an example of using flow control 
is given in a later section). 

In Linda, the ordering of messages is not 
guaranteed. For example, if one process 
executes two out operations in the follow¬ 
ing order: 

out(“x”, 1); 
out(“x”, 2); 

then a separate process doing an in opera¬ 
tion on the key “x” may receive the tuples 
in either order. The order is often unimpor¬ 
tant, but if not, an additional field in the 
tuple can be used to sequence the mes¬ 
sages. For example, both the sender and 
receiver can keep a local sequencing vari¬ 
able, initially set to zero. The out and in 
operations in Figure 2 are changed to 

// in the sender process 
out(“x”, send_sequence++, i); 

// in the receiver process 
in(“x”, recv_sequence++, ?j); 

and the correct order is guaranteed. If there 
are multiple senders or receivers, then the 
sequence variables can be shared by stor¬ 
ing them in tuple space. 

Linda provides decoupling between the 
sender and receiver of a message in both 
time and space. Messages are decoupled in 
time because the out operation is asynchro¬ 
nous and because messages travel via tuple 
space. Since messages can be held in tuple 
space, sending a message between two 
programs not running at the same time is 
even possible. This is crucial in an operat¬ 
ing system, where operating system ser¬ 
vices must be able to communicate with 
user programs that typically were not writ¬ 
ten when the operating system was written. 

Messages are decoupled in space be¬ 
cause individual messages are identified 
by their contents. Neither the sender nor 
the receiver needs to know the other’s 
identity or location. This allows communi¬ 
cation in Linda to be more dynamic than in 
systems where the sender and receiver of a 
message must explicitly rendezvous. In 
particular, sending and receiving pro¬ 
cesses can be located on any processor, or 
even dynamically moved between proces¬ 
sors, with no effect on the program. This 
important property of Linda facilitates 
writing parallel programs. 

Unlike some message-passing systems, 
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Linda is not limited to a single sender and 
receiver for a message stream. With the 
number of clients changing over time, this 
is useful for writing server processes, 
which receive messages from many differ¬ 
ent clients. In this case, if the client re¬ 
quires a message in return, it should iden¬ 
tify itself in the message to the server so the 
server can respond to the correct client. 

Implementing Linda. At first glance, it 
might appear that tuple matching requires 
searching tuple space for each operation, a 
process that would clearly be too slow for 
use on a parallel computer. Fortunately, a 
number of techniques are used to speed up 
the matching process. The goal of these 
techniques is to reduce the amount of 
searching necessary and make the remain¬ 
ing searching as efficient as possible. 

The most common approach to making 
Linda more efficient is to use a preproces¬ 
sor to reduce or eliminate runtime search¬ 
ing. 4 The preprocessor analyzes a Linda 
program to determine the patterns of tuple 
usage. For example, consider a Linda pro¬ 
gram that contains two processes. The first 
process contains a single out operation: 

out(“x”, i); 

and the second process contains a single in 
operation: 

in(“x”, ?j); 

where i and j are integer variables. Since 
the key “x" is a constant at compile time, 
the Linda preprocessor determines that this 
pair of Linda operations can be imple¬ 
mented as a queue between the variables i 
and j. On a shared-memory system, this 
could be realized as a shared queue pro¬ 


tected by a semaphore; on a distributed- 
memory system, this could be realized as 
an asynchronous message send. Thus, no 
searching is done, and the most efficient 
implementation for the target architecture 
is used without changes to the program’s 
source code. In this case, there is no over¬ 
head from the use of Linda. 

Using a preprocessor is not always pos¬ 
sible if Linda is used, for example, with 
interpreted languages such as Lisp, Post¬ 
script, Smalltalk, or Prolog, since tuple 
space usage can change while the program 
is running. Even with compiled languages, 
determining tuple space usage is not al¬ 
ways possible at compile time if the pro¬ 
grams that will be communicating cannot 
be preprocessed at the same time (in par¬ 
ticular, for communication between the 
operating system and a user program). 

A common technique used by Linda 
implementations that do not use a pre¬ 
processor is to restrict the key to a single 
field. In this case, hashing is used so the 
search can be performed (on average) in 
constant time. The performance of such an 
implementation is quite acceptable, since 
the overhead of a hashing function is rea¬ 
sonably small compared with the cost of 
data transfer on a typical system. Allowing 
but a single key in a tuple places some 
restrictions on Linda, but Linda’s main 
advantages — including portability and 
decoupling in time and space — remain. 
For instance, all examples of Linda in this 
article need only a single key. 

A third technique used to make Linda 
more efficient is to split tuple space into 
smaller pieces, for example, through the 
use of multiple tuple spaces; doing so, less 
space needs to be searched even if search¬ 
ing is required. This technique is also help¬ 
ful for systems that use hashing, since 
smaller hash tables can be used. 

Kernel Linda 

Until now, Linda has been used primar¬ 
ily to support application-level program¬ 
ming. To use Linda for system-level pro¬ 
gramming, a number of modifications 
were made. This section discusses those 
modifications and shows how they benefit 
system-level programming. 

Kernel Linda is a version of Linda de¬ 
signed to be used for system-level pro¬ 
gramming, as the interprocess communi¬ 
cation (IPC) mechanism for a parallel 
operating system. 5 Kernel Linda was also 
designed for use as the runtime system for 
the original Linda. In this case, the Linda 
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preprocessor is used to generate calls to 
Kernel Linda, rather than to the normal 
Linda runtime library. This allows pro¬ 
grams written in Linda to be integrated into 
an operating system based on Kernel 
Linda. 

Since Kernel Linda is designed to sup¬ 
port communication between operating 
system processes and user processes, a 
preprocessor cannot be used to speed up 
tuple space operations. Consequently, for 
efficiency, tuples in Kernel Linda are al¬ 
lowed to have only a single key. Except for 
the single-key restriction, Kernel Linda is 
a superset of Linda and includes the fol¬ 
lowing extensions: 

• multiple tuples spaces, 

• the ability to store a tuple space as a 
field of a tuple, and 

• a set of language-independent 
data types. 

In addition, the ordering of tuples in 
tuple space is guaranteed in Kernel Linda. 
If one process executes the following out 
operations in the following order: 

out(“x”, 1); 

out(“x”, 2); 

then a separate process doing an in on the 
key “x” is guaranteed to receive the values 
1 and 2 in that order (assuming that no 
other Linda operations use the key “x” in 
this tuple space). This avoids the need for 
extra sequencing keys, and also means that 
Kernel Linda can be used to transmit a 
stream of ordered messages from one pro¬ 
cess to another. 

Multiple tuple spaces. Kernel Linda 
incorporates a unique implementation of 
multiple tuple spaces that allows the tuple 
space name to be used somewhat like an 


additional key in a tuple. In traditional 
Linda, multiple keys in a tuple are often 
used to restrict communication to specific 
data structures; in Kernel Linda, this func¬ 
tion can be more efficiently performed 
using multiple tuple spaces. The provision 
of multiple tuple spaces removes much of 
the need for multiple keys. 

For example, in the out operation 

// which row in the matrix 

int RowNumber; 

// data for the row 

float data[SIZE]; 

out(“MatrixA”, RowNumber, data); 

the constant “MatrixA" identifies a spe¬ 
cific data structure, and the identifier 
RowNumber identifies a specific row in the 
matrix. A specific row of the matrix would 
be retrieved by searching on the first two 
keys: 

int RowNumber = 42; 

rd(“MatrixA”, RowNumber, ?data); 

In Kernel Linda, the need for multiple 
keys can be eliminated by placing matrix 
A in its own tuple space, with the key 
being the row number. This also reduces 
the amount of searching required, since 
the name of the matrix is not used as a 
key during matching. In Kernel Linda, 
the above out operation would be written 
(in C) as 

out(aMatrix, RowNumber, data); 

where aMatrix is the name of a Kernel 
Linda tuple space. In C++, the special role 
of the tuple space is syntactically high¬ 
lighted: 

aMatrix.out(RowNumber, data); 


The provision of multiple tuple spaces 
has other benefits for parallel program¬ 
ming. In a single global tuple space, name 
conflicts can occur between programs us¬ 
ing the same key to identify tuples. Mul¬ 
tiple tuple spaces allow communication to 
be more structured. In a multiapplication 
environment, some tuple spaces can be 
local to specific applications, while other 
tuple spaces can be common to some or all 
applications. This allows Kernel Linda tc 
support both multiprogramming (separate 
applications running concurrently) and 
multiprocessing (single applications run¬ 
ning on multiple processors). 

Subsequent to our implementation of 
multiple tuple spaces in Kernel Linda, 
another design for multiple tuple spaces 
was done for Linda as part of the design of 
Linda 3, although it is not the type of 
system we describe here. 6 

Tuple spaces as tuple fields. Kernel 
Linda allows a tuple space to be used as a 
field in a tuple, which allows Kernel Linda 
to be used as its own name service. This is 
done by using a name as the key and the 
tuple space as the value of a tuple in an¬ 
other tuple space. No other naming mecha¬ 
nism is required. A tuple space can be used 
like a directory in a hierarchical file sys¬ 
tem, except that arbitrary graphs can be 
constructed. For example, all tuples spaces 
associated with an application can be given 
“names” by storing them in a tuple space, 
or one process can be given access to a 
tuple space owned by another application 
via a common tuple space. This is dia¬ 
gramed in Figure 3, where process P is 
computing with three matrices: A, B, and 
R, and a separate process Q has been given 
access to the R (result) tuple space. 

Language-independent data types. 

Linda is traditionally implemented to work 
within a single language and borrows the 
data types from that language. Kernel 
Linda is designed to work with many dif¬ 
ferent languages (both compiled and inter¬ 
preted), so it provides a set of language- 
independent data types. For example, this 
allows a tuple space created by a C++ 
program to be accessed by a debugger or 
tuple space browser written in Postscript. 

In traditional Linda, all fields in a tuple 
are passed by value. This is reasonable for 
small fields, such as numbers or even 
names. But, for large fields, such as struc¬ 
tures or long character strings, this can 
result in extra copying. Passing some types 
by reference avoids this extra copying. 
More importantly, if a tuple space is to be 
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passed as a field in a tuple, it must be 
passed by reference, because two pro¬ 
cesses must have references to the same 
tuple space to communicate. Conse¬ 
quently, the Kernel Linda data types are 
divided into two groups, simple (pass-by- 
value) and composite (pass-by-reference). 
The simple types are 

int a 32-bit integer 

real a 32-bit floating-point 

number 

real64 a 64-bit floating-point 
number 

name an atomic identifier 
struct a structure containing user- 
supplied data 
null the error value 

The simple types are always passed by 
value. If a process passes one of these 
objects to another process (for example, 
via tuple space), each process will have a 
separate copy of the object, so modifying 
the object in one process will not affect the 
value of the object to the other process. 
The composite types are 

diet a Kernel Linda tuple space 

(dictionary) 

string a string of characters 
block an array of bytes 
array a heterogeneous array of 
other Kernel Linda objects 

Composite types are always passed by 
reference; if a process passes one of these 
objects to another process (again, typically 
via tuple space), then both processes will 
have a reference to the same object, even if 
the processes are on different processors. 
Thus, modifying the object in one process 
will affect the value of the object to the 
other process. This is the only Kernel Linda 
communication mechanism; modifying a 
shared object. In particular, the Linda 
operations (in, out, and rd) modify shared 
dictionaries. Shared objects are imple¬ 
mented on a distributed-memory computer 
using a mechanism called locators, de¬ 
scribed in the next section. 

Of course, it is possible to make a copy 
of a Kernel Linda object. Making a local 
copy of an object that was passed by refer¬ 
ence gives the equivalent semantics as 
pass-by-value. 

A diet (dictionary) is the Kernel Linda 
name for a tuple space. A tuple in a diction¬ 
ary consists of a single key/value pair. The 
keys are almost always names or integers 
but can be of any data type. A value asso¬ 
ciated with a key in a dictionary can also be 
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of any type, for example, another diction¬ 
ary. Tuples are only allowed to have a 
single value, but this value can be a struc¬ 
tured object, such as an array, which holds 
multiple values. As in Linda, multiple 
copies of the same tuple can be held in 
tuple space; this corresponds to a key in a 
Kernel Linda dictionary having multiple 
values. 

To allow the user to choose between 
value and reference semantics, strings and 
names are essentially the same type, ex¬ 
cept that strings are passed by reference 
and names are passed by value. The same 
is true of blocks and structs. This allows 
copying to be avoided, if desired. For 
example, names are typically used as keys 
in tuples, while strings are used for long 
strings of text such as shell scripts. Like¬ 
wise, an executable load module is nor¬ 
mally stored as a block to avoid making 
extra copies, but simple data structures, 
corresponding to a struct in C, are normally 
stored as a Kernel Linda struct. 

Implementation. Kernel Linda evolved 
through several implementations, both on 
single-processor and distributed-memory 
computers. On a single-processor com¬ 
puter, and within a single processor on a 
distributed system, Kernel Linda is imple¬ 
mented as a shared-memory-model pro¬ 
gram. Internally, composite objects are 
protected by a semaphore to guard against 
concurrent updates. This semaphore is 
controlled by the system and is not visible 
to the user. 

The implementation on a distributed- 
memory computer, where a distributed- 
memory-model program is used, is much 
more interesting. In this case, composite 
objects are manipulated using a form of 
distributed pointer called a locator, which, 
in addition to other information, contains 
the processor ID of the processor on which 
the object is located. When an operation is 
to be performed on a remote object, a 
message is sent to the processor containing 
that object, and a server process on the 


remote processor performs the operation. 
When an operation is to be performed on a 
local object (including operations by the 
server process after receiving a request 
from a remote processor), the shared- 
memory-model program is used. The im¬ 
plementation of Kernel Linda on a shared- 
memory computer is more straightforward 
than the one for the distributed-memory 
computer because it avoids the remote 
server process. 

Despite the fact that Kernel Linda does 
not use a preprocessor, the overhead com¬ 
pared to that of message passing is reason¬ 
able. This overhead arises mainly from 
evaluation of the hashing function, any 
required searching within the hash table, 
and the locking of a semaphore. For trans¬ 
fers of reasonable amounts of data the 
overhead is about 10 percent, rising to as 
much as 50 percent for shorter transfers (a 
synchronization with no data transfer 
being the worst case). This is comparable 
to the overhead of higher level languages 
such as C, and, of course, when this over¬ 
head is unacceptable, the user can drop 
down into machine primitives, analogous 
to the way C programmers can drop down 
into assembly language. 

QIX 

QIX (pronounced “quicks”) is a paral¬ 
lel, dynamically reconfigurable, server- 
based operating system implemented on a 
distributed, message-passing computer 
based on the Inmos transputer. Further 
implementations on other machines, in¬ 
cluding shared-memory computers or even 
single-processor computers, would also be 
reasonable. 

To the user, QIX appears almost identi¬ 
cal to Unix but, below the surface, it is 
considerably different. In terms of exist¬ 
ing versions of Unix, QIX is most like 
Mach, 7 except that Mach is based on a 
message-passing model, while QIX uses 
Kernel Linda. Like Mach, QIX has a small 
operating system kernel that is replicated 
on each processor. The QIX kernel pro¬ 
vides the lowest level of operating system 
facilities: 

• memory allocation, 

• process creation, scheduling, and 
synchronization, 

• device drivers, and 

• Kernel Linda. 

The remainder of the operating system is 
implemented by servers, which communi- 
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Figure 4. Accessing system services via Kernel Linda. 


cate with each other using Kernel Linda. 
These servers implement a high degree of 
compatibility with Unix System V, with 
one significant exception: the process 
model. 

As mentioned earlier, the Unix process 
model, which was developed for pseudo 
parallelism, is largely unsuitable for true 
parallel programming. Parallel computers 
that run Unix typically supply a second 
process creation mechanism for light¬ 
weight processes, resulting in two inde¬ 
pendent, incompatible mechanisms, one 
for parallel programs and one for compati¬ 
bility with Unix. Put another way, these 
operating systems provide one process 
creation mechanism for pseudo parallel¬ 
ism (multiprogramming) and a separate 
mechanism for true parallelism (multi¬ 
processing). 

For true parallel programming, it is very 
important that process creation be as inex¬ 
pensive as possible. Unix process creation, 
based on the fork and exec primitives, is 
relatively costly because a copy of the 
image space of a process is made, file 
descriptors are duplicated, and so on. The 
fork primitive is especially impractical on 
a distributed-memory computer, since 
standard optimizations such as copy-on- 
write cannot be used. 

Those of us who developed QIX at 
Cogent Research wanted a single process 
creation mechanism that would serve both 
true and pseudo parallelism, while main¬ 
taining as much compatibility with Unix as 
possible within the absolute requirement 
for efficiency. We also wanted it to be easy 
to use and thus encourage programmers to 
write parallel programs. Once again, Linda 
proved invaluable, and the resulting pro¬ 
cess model is both simple and general. In¬ 
deed, the QIX process model would be 
suitable for use in a version of Unix de¬ 
signed for single-processor machines. 


Process environments. In Unix, each 
process executes within an environment, 
but the information that constitutes an 
environment is not embodied in a single 
object. Access to information in a Unix 
process environment is through several 
different mechanisms or, in some cases, is 
not possible. Using Kernel Linda, we were 
able to encapsulate the process environ¬ 
ment into a single object, which can be 
manipulated using normal Kernel Linda 
operations. 

Each process in QIX has a dictionary 
(tuple space) associated with it called its 
environment. The environment dictionary 
contains all information about a process 
and is the only access the process has to the 
outside world. Heavyweight (Unix-like) 
processes will naturally have quite a bit of 
information in their environment, while 
lightweight processes can have very 
simple environments. The time it takes to 
create a new process depends on how much 
information is put into its environment 
dictionary; anything from extremely light¬ 
weight (an empty environment) to ex¬ 
tremely heavyweight (even heavier than 
Unix!) processes can be created, or any¬ 
thing in between. 

The environment of a Unix-style heavy¬ 
weight process typically contains the fol¬ 
lowing keys: 

Parent : the environment dictionary of 
the parent process 
Exit: the exit code of this process 
Signal: where signals are sent 
Arguments: the command line 
arguments (argc and argv) 
Variables: Unix environment 
variables 

File Descriptors: an array of open file 
descriptors for this process 
Creation Mask: default file creation 
permissions 


Process ID: the process ID of this 
process 

Process Group: the current process 
group ID 

Processor ID: the processor this 
process is running on 
Working Directory: the current 
working directory 
Real IDs: the real user ID of this 
process 

Effective IDs: the current effective 
user ID of this process 
Root: for communication between 
unrelated programs 
Services: a dictionary containing the 
O/S servers 

Since the process environment is a Ker¬ 
nel Linda dictionary, it can be manipulated 
using normal Kernel Linda operations. 
Typical Unix operations on processes can 
be performed using normal Linda opera¬ 
tions on the process environment. For 
example, to wait until a process terminates 
and return its exit code, an rd operation can 
be done on the key “Exit" in the environ¬ 
ment dictionary for the process: 

env.rd(“Exit”, exit_code); 

Services. The “Services” key in the 
environment is particularly significant. 
The value of this key is another dictionary 
that contains keys for all of the operating 
system services. On a typical system, the 
“Services” dictionary contains the follow¬ 
ing keys: 

File: the file system 
Pipe: Unix pipe service 
TTY: serial ports 
Execute: the execution service 
Console: the system error console 
PIX: the parallel interactive executive 
window system 
Graphics: the graphics server 
Window: terminal emulator windows 
FTP: file transfer service 
Tape: file backup 

Null: the null device (like/dev/null) 

Processes gain access to operating sys¬ 
tem services by using Kernel Linda as a 
name service. For example, as Figure 4 
shows, to find the file service, a process 
looks in its environment for the key “Ser¬ 
vices” (using rd), and then in this diction¬ 
ary for the key “File." The value of this 
key is another dictionary: the dictionary 
for the file service. 

Once the file server dictionary is lo¬ 
cated, it is not necessary to walk this dic- 
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tionary chain again. A process communi¬ 
cates with the file system simply by doing 
Kernel Linda in and out operations on this 
dictionary. The file system server process 
normally sits blocked doing an in opera¬ 
tion on the key “request" in its dictionary 
so, when a process does an out to this key, 
the server wakes up and performs the ser¬ 
vice. For the file service, the out operations 
contain requests for read and write opera¬ 
tions on files and the in operations return 
the results of the file operations. Other 
operating system services perform simi¬ 
larly. A programmer can perform Linda 
operations to communicate with system 
services, if desired, but more typically 
access to these services is through a li¬ 
brary, which translates standard Unix calls 
into the appropriate Kernel Linda opera¬ 
tions. Thus, to the user, the file system is 
identical to Unix while, to the operating 
system, the files are handled by a server 
represented by a dictionary. 

Normally, all (heavyweight) processes 
share the same Services dictionary but, 
because the Services dictionary is just 
another dictionary, adding new services or 
replacing individual services on either a 
systemwide or a process-by-process basis 
is possible, using normal Kernel Linda 
operations. It is also possible to move ser¬ 
vices between processors, or to replicate 
servers on multiple processors for added 
performance; for example, there is a sepa¬ 
rate instance of the pipe service on each 
processor. Many servers, including the file 
service, are stateless; it is possible to 
change or even completely replace these 
services while the operating system is 
running. 

The same Linda debugging tools used to 
debug parallel programs can be used to 
browse around inside the operating sys¬ 
tem. For example, when writing this ar¬ 
ticle, I used the Kernel Linda browser to 
see what services were available on my 
system. 

Process creation. The use of Kernel 
Linda makes process creation in QIX easy 
(and quick!). 8 The same operations that 
create the environment for the new process 
also set up the communication paths for it. 

• The parent process creates a Kernel 
Linda dictionary (using the createdict 
call), and then adds as much informa¬ 
tion to this dictionary as desired. 
Heavyweight processes will have lots 
of information placed in their envi¬ 
ronment dictionary, while lighter 
weight processes will have less infor- 
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mation. Users can either place infor¬ 
mation in this dictionary explicitly 
(using the normal Kernel Linda opera¬ 
tions) or use library calls to create 
standard environments. Communica¬ 
tion paths between different processes 
in an application are created at the 
same time. 

• A new process is then created, using 
the execute call. The program can be 
read from a disk file, but if multiple 
copies of a process are to be created (as 
for a processor farm), then it is more 
efficient to load an executable pro¬ 
gram from disk into a Kernel Linda 
block. The execute call can then be 
used to create multiple copies of the 
process quickly, since no further disk 
activity is required. 

• The execute call can optionally take a 
processor ID that indicates the proces¬ 
sor to be used to execute the new pro¬ 
cess. If the user does not supply a pro¬ 
cessor ID, then the execution service 
(accessed using the “Execute" key in 
the “Services” dictionary) supplies an 
appropriate processor by consulting 
the Oracle. The Oracle is yet another 
Kernel Linda dictionary found in the 
dictionary for the execution service. 
The Oracle contains information on 
loading and memory usage for all 
processors in a system and also con¬ 
tains a method (which can be overrid¬ 
den) for choosing a processor on which 
to run a new process. The default 
method chooses a processor with 
enough memory to run the new process 
and which also has the lowest load. 

The QIX process creation mechanism 
also solves a problem with the eval opera¬ 
tor in traditional Linda. The eval operator 
is used to create new processes. For ex¬ 
ample, if fen is a function, then 


eval(“hello”, fcn(z), true); 

creates a new process to evaluate fen. 
Unfortunately, the semantics of the eval 
call are not well defined, because the envi¬ 
ronment of the new process is not speci¬ 
fied. For example, if fen uses any global 
variables, they might or might not be 
shared with the parent process or, if the 
tuple passed to eval contains more than one 
function to be evaluated, they might or 
might not share address space. Thus, in a 
conventional Linda system, the semantics 
of an eval operation will usually be very 
different on a shared-memory system as 
opposed to a distributed-memory system, 
making eval nonportable. In QIX, the 
environment for the new process is explic¬ 
itly specified. 

Lightweight process creation. The 

following is an example of a program that 
creates a new process from a program on 
disk and communicates with it. The envi¬ 
ronment for the new process contains only 
two keys, so creating it is very fast. Here is 
the code to spawn the new process: 

// the new environment dictionary 
Val new_env = createdict(); 

// the value of x is the integer 5 
new_env.out(“x”, (Val) 5); 

// the value of y is the integer 20 
new_env.out(“y”, (Val) 20); 

// read the executable file from disk 
Val proc = createblockfromfile(“foo”); 

// create a new process 

int pid = new_env.execute(proc); 

// collect results 
Val result; 

// read the value of z 
new_env.in(“z”, result); 
printf(“z = %d\n”, (int) result); 

A Val is a Kernel Linda value; in C++, 
all Kernel Linda objects are of C++ type 
Val but, as discussed before, these objects 
also have a Kernel Linda type. In the above 
program, the Val new env is of Kernel 
Linda type diet; x, y, and z are of Kernel 
Linda type int; and proc is of Kernel Linda 
type block. Here is the program for the new 
process to be created: 

// the process to be created 
void main() 

{ 

// access my environment 
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Figure 5. Processor farm using Kernel Linda. 


Val env = environment^); 

Val x, y; 

// read the value of x and y 
env.rd(“x”, x); 
env.rd(“y”, y); 
intz = (int) x + (int) y; 

// set the value of z 
env.out(“z”, (Val) z); 

) 

This program is compiled like any C++ 
program and placed in a file named “foo.” 
In this example, the values of the keys 
are integers to be added together; typi¬ 
cally, a much more complex calculation 
would be performed by the spawned pro¬ 
cess. 

In creating this process, we used the 
environment dictionary for communica¬ 
tion between the parent process and its 
child. Note that because the new environ¬ 
ment has no “Services” dictionary, the 
child process cannot access any operating 
system services beyond those in the Ker¬ 
nel. In particular, it must pass any results 
back to its parent, rather than printing them 
itself. To provide other operating system 
services, we need to create a more heavy¬ 
weight process. 


Heavyweight process creation. One 
way to create a more heavyweight process 
is to explicitly place all desired keys in the 
environment dictionary; there are a num¬ 
ber of shortcuts for doing this. For ex¬ 
ample, the ecopy call makes a copy of the 
current process environment suitable for 
use as the environment for a child process, 
so a heavyweight process can be created 
as follows: 

Val prog = 

createblockfromfile(“foo”); 

Val new_env = 
environment().ecopy(); 
int pid = new_env.execute(prog); 

Finally, there is a forkexecvp call that 
emulates the most common usage of the 
Unix fork and exec calls: 

// command line arguments 
char **argv; 

// file descriptors 
int *fds; 

// optional processor id 
int processor; 

int pid = forkexecvp(“foo”, 
argv, fds, processor); 


Parallel application 
programming in QIX 

In QIX, as in other operating systems, 
the same mechanisms for parallelism used 
by the operating system are used for writ¬ 
ing parallel application programs; but, in 
this case, the applications programmer can 
use Kernel Linda. This section gives a 
fairly complete example of how to use QIX 
to write a true parallel program. This ex¬ 
ample uses a form of parallel program 
called a processor farm, although many 
other forms are also possible. In a proces¬ 
sor farm, multiple worker processes per¬ 
form tasks assigned by a master (or task 
creator) process. The number of workers 
will usually vary according to the number 
of processors in the system. 

This example is applicable to graphics 
applications such as ray tracing, image 
processing, or computation of the Mandel¬ 
brot set, where there is an image to be 
computed and subareas of this image are 
portioned out as tasks to the various work¬ 
ers. Figure 5 diagrams the example. 

The task descriptors define the area of 
the image to be computed; for example, 

( 96, 160, 32, 32 ) 

defines a rectangular area of the image at x 
position 96, y position 160, and a width and 
height of 32 picture elements. This task 
descriptor is implemented as a C++ struct; 

struct task_descriptor ( 
int x, y, xsize, ysize; 

} td; 

td.xsize = td.ysize = 32; 

The task creator process places the task 
descriptors into its environment with a 
loop containing an out primitive: 

Val env = environment(); 

for (td.y = 0; td.y<y_image; 
td.y += td.ysize) 
for (td.x = 0; td.x < x Jmage; 
td.x += td. xsize)) 

Val tdval = createstruct( 
sizeof(td), (char*)&td); 
env.out(“task”, tdval); 

) 

Each worker process first gets a task 
descriptor from the environment of its 
parent. The worker then computes that part 
of the image, sends out the resulting pixels, 
and repeats the procedure until there is no 
more work to be done. 
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Figure 6. Dynamic load balancing in Kernel Linda. 


Val parent; 

environment().rd(“Parent”, parent); 

Val task; // to receive task descriptors 

Val result; // for resulting pixels 

while(l) { 

parent.in(“task”, task); 
task_descriptor* tdp = task.value(); 
// compute area of image 
result = compute(tdp->x, tdp->y, 
tdp->xsize, tdp->ysize); 
parent.out(“result”, result); 

) 

Sending task descriptor messages via 
tuple space means the task creator process 
need not be concerned with details about 
where the workers are located, nor even 
with how many workers there are. The 
number of workers can change even while 
the program is running. 

Flow control. In the processor farm 
example, no flow control exists between 
the task creator process and the workers, so 
it is possible for the task creator to over¬ 
flow memory. If we are creating only a few 
hundred task descriptors, then this would 
not usually be a problem; but, if it is a 
problem, flow control is relatively easy to 
implement in Linda. 

For example, the task creator can ini¬ 
tially send out a fixed number of task de¬ 
scriptors (typically twice the number of 
worker processes) and then block doing an 
in operation on the key “ack" in its envi¬ 
ronment. As each worker in’s a task de¬ 
scriptor, it also does an out operation to the 
key “ack." When the task creator receives 
an ack, it sends out a new task descriptor. 
Thus, the number of task descriptors re¬ 
mains fixed. 

Dynamic load balancing. To achieve 
optimal processor use, the processor farm 
model of parallel computation requires 
that each worker perform about the same 
amount of work. Unfortunately, work 
rarely distributes that evenly; one or two 
tasks will usually take much longer than 
others, causing the other workers to wait 
while those tasks complete. This is espe¬ 
cially true in graphics applications such as 
the ones considered above, where some 
tasks can take orders of magnitude longer 
than others. 

Using Linda, it is relatively easy to solve 
this problem. If one worker discovers that 
it has a particularly difficult area of the 
image to compute, it can subdivide its task 
into smaller tasks and send the new tasks 
off to other workers. As Figure 6 shows, 
workers do this by performing an out op¬ 


eration to the key “task" in the environ¬ 
ment of the task creator process (the same 
as the task creator would). Since messages 
are sent via tuple space, workers do not 
care whether the task descriptor they re¬ 
ceive was produced by the task creator or 
another worker. 

How workers decide whether their task 
is too complicated depends on the applica¬ 
tion. For example, in ray tracing, you might 
decide that if an area of the image contains 
more than a set number of objects, the area 
will be subdivided. Or for a Mandelbrot 
program, the black areas of the image are 
the most costly to compute, so we could 
keep track of the percentage of black points 
that have been computed and, if the per¬ 
centage exceeds a certain threshold, subdi¬ 
vide the area. The point at which a task is 
subdivided can even change dynamically. 

An alternative way to structure a pro¬ 
gram that uses dynamic load balancing is 
to eliminate the task creator process en¬ 
tirely, and initially create a single worker 
with a single task descriptor for the entire 
job. If the task is simple enough, that pro¬ 
cess can easily complete it without going 
to the trouble of creating any other work¬ 
ers. If the task is not that simple, then a 
new worker and task descriptor can be 
created, and so on recursively. Thus, the 
amount of parallelism can adapt to the task 
at hand. This eliminates creating processes 
that will have little or nothing to do, for 


example, creating hundreds of worker 
processes to create a blank image. When 
the number of workers and available pro¬ 
cessors is roughly the same, load balanc¬ 
ing can still be done by subdividing task 
descriptors, but without creating new 
worker processes. 

PIX. One of the best ways to determine 
the power and efficiency of a new software 
paradigm is to actually build a reasonably 
large application with it. To test the ideas 
in Kernel Linda, we decided to write a 
window system, which is a substantial 
project. We also decided that, like the 
NeWS window system from Sun Mi¬ 
crosystems and NextStep user interface 
from Next, we would base this window 
system on the Postscript graphics language 
that Adobe Systems, Inc. developed. Writ¬ 
ing a Postscript interpreter itself is no small 
task; writing a Postscript interpreter that is 
fast enough for interactive use is harder 
still; and the conventional wisdom says 
that writing a parallel program is harder 
than writing a sequential program, so we 
decided that writing a parallel interactive 
Postscript interpreter would be a good trial. 

The resulting window system, PIX 
(parallel interactive executive), is in daily 
use on a distributed computer (the Cogent 
Research XTM), and is certainly fast 
enough for interactive use. Linda handles 
all communication, even down to tracking 
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mouse movement. Total development time 
was about 2 person-years, although we felt 
the choice of C++ as the implementation 
language also had a favorable effect on 
development time. 

Also interesting was how the use of 
Kernel Linda allowed us to significantly 
improve the window system design. For 
example, one of the more innovative fea¬ 
tures of the NeWS window system is the 
addition of quasi-parallelism to Postscript. 
New Postscript processes can be created, 
and they communicate using two different 
mechanisms: shared memory protected by 
monitors, and a message-passing system 
called events. NeWS uses this parallelism 
to deal with the inherent concurrency of 
human-computer interaction. But, in 
NeWS, this parallelism is simulated inside 
a single Unix process because Unix pro¬ 
cess creation is so expensive, and Post¬ 
script processes run nonpreemptively 
(each process runs to completion unless it 
explicitly gives up control). This can be 
disconcerting to the window system user, 
since windows that are supposed to be 
executing in parallel often don’t, due to 
time-consuming processes effectively 
locking out any other user interaction. 

Under QIX, we were able to implement 
PIX as a true parallel program. In PIX, the 
Postscript processes are individually 
scheduled processes, and they communi¬ 
cate using Kernel Linda. To do this, we 
added a Kernel Linda binding to Post¬ 
script, using Postscript dictionaries as 
tuple spaces. Kernel Linda eliminates the 
need to use dangerous shared memory and 
replaces the complicated and slow NeWS 
event-matching process. 9 We found that 
using Linda not only makes programming 
user interfaces in Postscript much easier, 
but also results in a true parallel user inter¬ 
face that can run on multiple processors. In 
particular, PIX can reconfigure itself to 
take advantage of new processors as they 
are added to a system, so the user interface 
can distribute along with an application. 
Thus, the user interface does not become a 
bottleneck. 


K ernel Linda is a variant of Linda, 
designed specifically to support 
system-level programming on 
parallel computers. The use of Kernel 
Linda was a significant factor in the design 
and implementation of the QIX operating 
system. QIX is neither a shared-memory or 
distributed-memory model operating sys¬ 
tem, but combines many of the best fea¬ 


tures of both, with some significant added 
features, such as a simple and powerful 
naming mechanism. 

The QIX operating system provides a 
powerful environment that makes it easier 
to write parallel programs, featuring 

• Unix-compatible system calls and 
utilities, 

• familiar languages, 

• Linda extensions, and 

• a powerful user interface. 

Using Linda makes it easy to write pro¬ 
grams that are independent of architecture 
or topology. Indeed, because the QIX 
operating system, PIX window system, 
and other utilities are written using Kernel 
Linda, they automatically reconfigure 
themselves to take advantage of new pro¬ 
cessors as they are added to a system. 

Linda is a high-level tool. It allows the 
programmer to concentrate on writing 
parallel programs and leaves the details to 
the operating system. 

In addition to supporting the writing of 
true parallel programs, QIX also supports 
traditional multiprogramming. Since 
multiprogramming increases hardware 
utilization by allowing several users or 
programs to share processor resources, and 
multiprocessing increases user productiv¬ 
ity by decreasing program turnaround 
time, QIX helps maximize utilization of 
both computing and programmer re¬ 
sources. ■ 
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Process Groups and Group 
Communications: 

Classifications and 
Requirements 

Luping Liang, Samuel T. Chanson, and Gerald W. Neufeld 
University of British Columbia 


G roup communication is an operat¬ 
ing-system-level abstraction that 
offers convenience and clarity to 
the programmer. Currently, only a few 
operating systems support this abstraction. 
However, a lack of understanding of group 
communication requirements with respect 
to different classes of applications may be 
equally responsible for the abstraction’s 
not being widely used. 

This article examines different distrib¬ 
uted applications and outlines their re¬ 
quirements for group communication sup¬ 
port. On the basis of internal structures and 
external behavior, we classify groups into 
different categories and discuss their prop¬ 
erties. 

In distributed computer networks, 
multicast (one-to-many communication) 
is a message transmission mechanism that 
delivers a message from a single source to 
a set of destinations. Special cases of 
multicast are unicast (one-to-one commu¬ 
nication) and broadcast (one-to-all com¬ 
munication). As Figure 1 shows, a single 
multicast transmission delivers a message 
to a set of destinations in parallel, allowing 
the receivers to process the message con¬ 
currently. 

In contrast to multicast, an abstraction 
of network communication, group com¬ 
munication is an operating-system-level 


To design a general, 
coherent, and integrated 
group communication 
system, we must 
understand basic 
application 
requirements. This 
classification of group 
applications can be an 
important tool. 


abstraction. A group is a composite of 
objects sharing common application se¬ 
mantics, as well as the same group identi¬ 
fier and/or multicast address. (Multicast 
exists at the medium-access sublayer with 
multicast hardware. The mapping between 
group identifiers and multicast addresses 
is implementation dependent and not nec¬ 


essarily one-to-one.) Each group is viewed 
as a single logical entity, without exposing 
its internal structure and interactions to 

Generally, objects are grouped for (1) 
abstracting the common characteristics of 
group members and the services they pro¬ 
vide, (2) encapsulating the internal state 
and hiding interactions among group 
members from the clients so as to provide 
a uniform interface to the external world, 
and (3) using groups as building blocks to 
construct larger system objects. Passing 
messages to a group is generally called 
intergroup communication. 

Group communication offers improved 
efficiency and convenience because 

(1) it delivers a single message to mul¬ 
tiple receivers by taking advantage of a 
network’s multicast capability, thereby 
reducing sender and network overhead; 

(2) it provides a high-level communica¬ 
tion abstraction to simplify user programs 
in interacting with a group of receivers; 
and 

(3) it hides from applications the inter¬ 
nal coordinations of a group (for example, 
membership changes). 

Group communication is best supported 
by network multicast. It can also be emu- 
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lated by one-to-one interprocess commu¬ 
nication or simulated by network broad¬ 
cast. However, in the former case, not only 
is the first advantage lost, but a sender must 
also keep track of every group member; 
thus, groups are no longer self-contained. 
With network broadcast, extra overhead is 
required because all machines must exam¬ 
ine every message regardless of its destina¬ 
tion; furthermore, the communication is 
less secure, since group messages can be 
seen outside a group. 

Although multicast was introduced a 
few years ago, 1 few applications take ad¬ 
vantage of group communication. The 
reasons for this are (1) a lack of under¬ 
standing of group communication require¬ 
ments with respect to different classes of 
applications; (2) the fact that few systems 
provide sufficient group communication 
support at the operating system level to 
meet those requirements; and (3) until 
recently, a lack of multicast hardware 
support. 

This article deals with the first part of the 
problem. We classify groups on the basis 
of their structure and behavior and present 
a uniform treatment of group transparency. 
Readers interested in the second part 
should refer to the literature. 1 ' 7 Other work 
in the area includes that of Mockapetris, 8 
who presents a general analysis of multi¬ 
cast mechanisms at the network level 
rather than at the application level. Hughes 
presents a multicast taxonomy based on 
the number of replies to each multicast 
request. 9 However, there is no general 
examination and classification of group 
communication requirements from the 
application’s point of view. 

We will define the process group model 
and classify it on the basis of the homoge¬ 
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Figure 2. Inter- and intragroup com¬ 
munications. 


neity of the structure among group mem¬ 
bers. Then we will examine different dis¬ 
tributed applications and their require¬ 
ments for group communication support, 
classifying groups according to their be¬ 
havior. We will also discuss the relation¬ 
ship between the two classifications. 

Process group model 

The concept of a process group is not 
new. V 1 and Isis 2 defined a process group 
as a set of processes grouped to coopera¬ 
tively provide a service. This definition, 
although broad, does not adequately char¬ 
acterize why or how the processes are 
grouped and hence does not provide suffi¬ 
cient information for classification. 

We refine the process group definition 
as follows: First, we define an object as a 
set of variables and a set of operations on 
those variables. We define an object group 
as a set of objects sharing one or more 
common characteristics (internal state), 
interacting and coordinating among them¬ 
selves to provide a uniform external inter¬ 
face. Second, because each object is gener¬ 
ally maintained by a manager process and 
can be accessed only through a request to 
its manager, we define a process group 
corresponding to a given object group G as 
the set of manager processes maintaining 
the objects in G. 

Process group members control the way 
resources in the object group are accessed 
and may have to coordinate among them¬ 
selves to maintain state consistency in the 
object group. Members also interface with 
users of the resources they maintain. Group 
messages are generally sent to process 
groups. 



Server group 


Figure 3. Many-to-many (group-to- 
group) communications. 


This model provides a better under¬ 
standing of group communication and al¬ 
lows classification on the basis of process 
group structure. For simplicity, we will use 
the term “group” to refer only to process 
groups. 

In distributed systems, machine bounda¬ 
ries prevent processes on different hosts 
from physically sharing memory. In the 
following discussions, unless stated other¬ 
wise, we assume that interaction with ob¬ 
ject groups occurs through intergroup 
communication at the process level. The 
underlying network can be either a local 
area network or an internet. We make no 
assumption regarding the implementation 
of group communication. 

A group is “closed” when only its 
members are allowed to send requests to it; 
otherwise, it is “open.” In this article we 
will use the open model, as it is more 
general and corresponds to the client- 
server model commonly used in distrib¬ 
uted operating systems. 

In the client-server context, the process 
invoking an operation is called a client and 
the process receiving and processing the 
invocation is called a server. A process can 
play both client and server roles, depend¬ 
ing on its communication context. This 
client-server model can be extended into 
group communication; that is, client group 
and server group can be defined similarly. 
As Figure 2 indicates, communications 
between external clients and a server group 
are called intergroup communications, 
while internal communications among 
group members are known as intragroup 
communications. Intergroup communica¬ 
tions could also occur between groups in 
the form of many-to-many communica¬ 
tions, as Figure 3 shows. 
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Sending messages from a single process 
to a group is called one-to-many communi¬ 
cation, and from a group to a single process 
is called many-to-one communication. 
Usually, many-to-many communications 
can be decomposed into one-to-many and 
many-to-one communications. 4 Also, as 
Figure 4 shows, a process can maintain 
multiple objects that may belong to differ¬ 
ent object groups. Therefore, a process can 
belong to multiple groups, and process 
groups can overlap. 

Structural 

classification 

Viewed as a collection of object manag¬ 
ers, a group can be classified on the basis of 
the homogeneity of the internal state of the 
objects maintained and operations sup¬ 
ported by each group member. An object 
manager can be characterized by 

• Application-level objects — the set of 
objects maintained by the process. Their 
value determines the application-level 
internal state of this process. 

• Application-level operations — the set 
of operations that can be executed on the 
above objects. Other processes can modify 
the value of these objects only by invoking 
these operations through this manager. 

Operations on the objects are what define 
the services a process provides. Because 
services of a process are accessed through 
interprocess communication in message¬ 
passing systems, operation executions and 
process state transitions are stimulated by 
the events of message arrival. 

A selection rule of a group G is a set of 
criteria for selecting objects forming G and 
is determined by G’s application. For 
simplicity, we assume that an object is in 
the object group G if and only if the object 
satisfies G’s selection rule, and that a 
process p is in the manager group of G if 
and only if p maintains at least one object 
satisfying that rule. The services a group 
provides are implemented by the group 
members cooperatively and are accessed 
by clients through intergroup communica¬ 
tion. A group G can be characterized by 

• Group objects — the subset of objects 
maintained by each member process in 
G, which satisfies G’s selection rule. 

• Group operations — the set of opera¬ 
tions on the above objects. 

Depending on how each group member 



Figure 4. Communication pattern for 
overlapping groups; G. = process 
groups, OG. = object groups. 


implements and maintains objects and 
operations, a group can be placed in one of 
four categories: 

(1) Data and operation homogeneous 
(DOH): Every member in a DOH group 
maintains a complete replica of the set of 
group objects and implements an identical 
set of operations on these objects. To guar¬ 
antee consistent external behavior, a DOH 
group maintains consistency among repli¬ 
cas of the objects and requires every 
member to execute exactly the same se¬ 
quence of operations. DOH groups are 
used mainly to increase service reliability 
and availability. Examples are groups in 
Isis 2 and troupes in Circus. 4 

(2) Operation homogeneous only 
(OHO): In an OHO group, the object space 
is partitioned among group members, with 
each member maintaining only part of the 
global group state. Object space partitions 
may overlap. Also, every member supports 
an identical set of operations on its portion 
of the objects. However, when an opera¬ 
tion is invoked on an object, only members 
with the relevant object need to perform 
the operation. OHO groups are used mainly 
to distribute the work load among group 
members. Each member can maintain the 
integrity of its own objects independently 
of other members. The distributed name 
service, discussed later, is an example of 
the OHO group. 10 

(3) Data homogeneous only (DHO): 
Members in a DHO group share a set of 
objects by sharing the same address space 
on a single machine, or in some other 
distributed manner (for example, data rep¬ 
lication). Each member supports a set of 


operations on the same objects. These 
operations may or may not be identical to 
those of other members. Upon invocation 
of a group operation, members may act 
differently. For example, a coordinating 
member accepts an operation invocation 
from a client and accomplishes the task 
through internal cooperation with other 
group members. The role of coordinator 
need not always be played by the same 
member. Also, members in a DHO group 
must synchronize themselves to serialize 
concurrent updates to the objects. This 
requires an underlying mechanism similar 
to that for DOH group support. The usual 
purposes of a DHO group are to provide 
group services cooperatively via a set of 
worker processes and to simplify the de¬ 
sign, implementation, and interface of the 
service by masking member cooperation 
from external observation. Examples in¬ 
clude the team in V" and the primary¬ 
secondary replication scheme. 612 

(4) Heterogeneous (Het): As far as the 
group application is concerned, the objects 
and operations each member implements 
and maintains could both be heterogene¬ 
ous. There may or may not be cooperation 
among group members, and their internal 
states may be completely independent of 
one another. Rather than encapsulate inter¬ 
actions among members to provide a coop¬ 
erative group service, heterogeneous 
groups facilitate system control and sim¬ 
plify interactions between the client and 
server groups. Electronic mail distribution 
lists, computer conferencing, news groups, 
and distributed process control are appli¬ 
cations of heterogeneous groups. 

Behavior classification 
and requirements 

According to their external behavior, 
distributed process groups can be classi¬ 
fied into two major categories: determinis¬ 
tic and nondeterministic. The former 
groups are used mainly in replicating data 
and services to enhance reliability, while 
the latter are used mainly in distributing 
data and work load among multiple servers 
to improve information availability and 
resource sharing. More complete defini¬ 
tions of the two categories appear later. 

Basically, a deterministic group requires 
high reliability in group communications 
to maintain strong consistency among 
members. Such groups are “heavyweight” 
in the sense that they require complete 
group membership information and 
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atomic, consistently ordered group inter¬ 
actions. In contrast, nondeterministic 
groups are “lightweight,” since they need 
only basic datagram multidelivery trans¬ 
port support. Inconsistencies and unreli¬ 
able group interactions are handled in an 
application-specific manner, resulting in 
more flexible and efficient — but more 
complex — application programming. 
Whether a group is deterministic or nonde¬ 
terministic depends solely on its applica¬ 
tion, not on its structural characteristics. 

Deterministic groups. A group is deter¬ 
ministic if each member must receive and 
act on a request. (The term deterministic is 
used here to characterize the relationship 
among group members and is less restric¬ 
tive than when used by some authors to 
mean only one possible execution of a 
single procedure.) This requires coordina¬ 
tion and synchronization among group 
members. In most deterministic groups, 
member processes are equivalent ; 4 upon 
receiving the same request in the same 
state, the same procedure is invoked, and 
every member transfers to the same new 
state and produces the same response and 
external effects. 

Let’s look at some deterministic-group 
applications in terms of their basic charac¬ 
teristics and communication requirements. 

Replicated file systems. In a fully repli¬ 
cated file system, all file servers constitute 
a group. Files are replicated at every file 
server to enhance file availability and re¬ 
liability. The two common methods sup¬ 
porting replicated file systems are peer- 
member and primary-secondary , 3 In the 
peer-member scheme, all members in a file 
server group are identical, and group 
communication and coordination occur 
between the client and all members. In the 
primary-secondary scheme, a primary 
member handles the communication inter¬ 
face between clients and the group, and 
group communication and coordination 
occur between the primary and all secon¬ 
daries inside the group. A fully replicated 
file server group is a deterministic DOH 
group if the peer-member scheme is used; 
it is a deterministic DHO group if the 
primary-secondary scheme is used. 

Replication transparency is an impor¬ 
tant characteristic of these systems. File 
system clients usually prefer a single file 
image regardless of whether a file is imple¬ 
mented by one or many servers. The file 
abstraction as seen by a client is called a 
logical file image, and operations on it are 
called logical operations. The physical file 


Distributed process 
groups can be classified 
into two major 
categories: deterministic 
and nondeterministic. 


copies maintained by the file servers are 
known as file replicas, and operations on 
them are called physical operations. Relia¬ 
bility requires that file replicas be kept 
consistent at all servers, so that files are 
always available to clients as long as at 
least one file server is functioning. Availa¬ 
bility requires that users be able to read the 
files with minimum latency — for ex¬ 
ample, to get a consistent copy of a file 
from the closest functioning server. 

Both reliability and availability imply 
that file replicas must be consistent. Thus, 
every logical file update must be atomic, 
that is, either executed by all servers or by 
none, and a client must be informed of 
whether or not its update is completed. 
Furthermore, because different sequences 
of the same set of update operations can 
result in different file states, all servers 
must execute exactly the same sequence of 
operations with respect to each logical file. 
Two logical operations, op, and op 2 , are in 
conflict if they are data dependent; since 
they manipulate overlapping logical data, 
the execution order affects the results. Two 
conflicting operations collide if executed 
concurrently. 

Consider two clients, C, and C 2 , who 
issue a LockFile request independently to 
acquire a lock on the logical file F. If the 
two requests are not consistently ordered 
at all server group members, some servers 
may allocate the physical locks on their 
physical replicas of F to C,, others to C 2 , 
depending on whose request is executed 
first; thus, a deadlock may occur. Clearly, 
collided operations must be ordered; the 
order can be arbitrary as long as it is consis¬ 
tent at all member sites. This ordering of 
collided operations is called absolute or¬ 
dering. 2 

File servers can be added or deleted 
dynamically. Clients expect the file server 
group to coordinate internally to hide 
membership changes from external obser¬ 


vation. This type of internal coordination 
includes keeping consistent name binding 
between a group identifier and a set of 
server process identifiers, and bringing a 
new server state up to date. Satisfying this 
requirement not only simplifies the group 
interface to clients but also increases flexi¬ 
bility in file system configuration. Since a 
host cannot always distinguish between 
network partition and host failure, file¬ 
system-level consistency requires that 
both clients and servers be notified when 
either failure occurs, and that some higher 
level consistency-control algorithms be 
used to handle the failure. 

Replicated program executions. Repli¬ 
cated program execution is another ex¬ 
ample of the deterministic DOH group. In 
some distributed applications, a major 
concern is the resiliency of computations. 
Programs can be decomposed into abstract 
data type modules, each having a set of 
internal states and a set of procedures 
manipulating the states. Modules are repli¬ 
cated on multiple sites, 4 and replicas of a 
module form a group. Group members may 
represent different implementations of the 
same abstract data type written by differ¬ 
ent programmers (subject to the constraint 
of equivalent deterministic behavior). 
Thus, module reliability can be enhanced 
by both replication and multiversion pro¬ 
gramming. Multiversion programming 
tends to reduce program design faults 
(assuming fail-stop behavior), while repli¬ 
cated module execution tends to make the 
module runtime execution robust. A pro¬ 
cedure call to a module can proceed as long 
as at least one group member is function¬ 
ing. An application programmer would 
expect the syntax and semantics of a repli¬ 
cated procedure call to remain the same as 
those of a nonreplicated call, that is, repli¬ 
cation transparent. 

Consistency in replicated procedure 
calls requires that the group members be 
deterministic and equivalent and that every 
member execute the same sequence of 
calls. Application programmers are re¬ 
sponsible for ensuring that modules are 
deterministic and equivalent. The group 
system, on the other hand, must guarantee 
atomicity and ordering (defined in the 
previous section) to each procedure call, as 
well as replication transparency. For each 
replicated procedure call from a client 
group to a server group, each client group 
member makes a one-to-many call to the 
server group, and each server group mem¬ 
ber accepts many-to-one identical proce¬ 
dure invocations (resulting from one call 
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per client group member) and makes a one- 
to-many reply to the client group after 
execution. Each client group member then 
handles many-to-one replies from the 
server group. These multiple calls and 
receptions are best handled in the group 
communication layer so that client/server 
programmers need not be aware of mul¬ 
tiple entities in the caller/callee group. 

An advantage of making replicated pro¬ 
cedure calls at the module level is that the 
degree of replication can be adjusted dy¬ 
namically according to the functions of 
different modules, thus optimizing system 
performance and reliability. In other 
words, more copies could be made for 
critical modules to enhance their reliabil¬ 
ity, while fewer or no replications would 
have to be made for less important mod¬ 
ules. Also, dynamically changing group 
membership allows system auto-recon¬ 
figuration to become transparent to appli¬ 
cations as group members fail and recover 
at runtime. However, this dynamic group 
membership makes it difficult to bind a 
group name to a set of modules. 

A replicated program execution often 
happens within a single local area network; 
therefore, network partition failure is un¬ 
likely. When any group member fails, the 
group is expected to reconfigure itself 
autonomously, making partial failures 
transparent to client groups. 

Distributed industry process control. 
Distributed process control is an example 
of the deterministic Het group. Imagine a 
simple distributed industry process control 
environment in which the temperature in a 
reaction container is to be controlled. A 
sensor measures the current value of the 
temperature, and a control panel displays 
that value to human operators, records the 
history of the sensor signals, and allows an 
operator to set the control parameters. A 
set of controllers manages the flow of 
cooling fluid into the container by opening 
or closing valves. The sensor can view the 
console and the controllers as a group. 
When a control parameter diverges from 
the preset value, the sensor multicasts the 
measured result to the group so that the 
console informs the operators and the 
controllers open or close the valves to 
adjust the flow automatically. 

This group is obviously heterogeneous 
because each member, though driven by 
the same sequence of signal stimuli, main¬ 
tains completely different objects and per¬ 
forms different operations. These compo¬ 
nents are grouped simply for convenience 
of communication; they are identified by a 


single receiver ID in each group message. 
If the underlying network supports multi¬ 
cast, only one copy is transmitted for each 
sensor signal, saving network bandwidth 
and speeding the signal processing. 

Although member states have no appli¬ 
cation-level consistency requirement, 
group communications have reliability 
requirements. Unless the sensor fails, its 
signals must be delivered reliably to all 
active members in the same order as gener¬ 
ated. Also, each signal from the sensor 
must be delivered by a predefined deadline 
or the signal will become obsolete. The 
sensor expects no reply from the group. 
Any individual member failure must be 
detected quickly, and operators must be 
notified to repair the failed component. 
However, before recovery of the failed 
component, the remaining group members 
are expected to continue fulfilling their 
duties even though the complete group 
service may not be available. 

E-mail distribution list and computer 
conferencing. Electronic mail distribution 
lists and computer conferencing are two 
other examples of the deterministic Het 
group. People registered in the same distri¬ 
bution list or conference constitute a 
group. Grouping is for convenience of 
communication; for each message, a 
sender prepares a single copy and performs 
one send operation. Generally, a sender 
does not know who participates in the dis¬ 
tribution list, because registrations are 
handled by an independent authority. The 
sender simply sends the message to the 
list’s address, which has the same syntactic 
format as other single-user addresses and 
which logically includes all participants. 
The same is true for computer confer¬ 
encing, except that conferences are nor¬ 
mally closed groups in which only partici¬ 
pants can send messages to the conference. 
In contrast, a distribution list is open to 
anyone with access to the list address. 

Assuming registration and network 
connections are set up properly, messages 
to a conference are expected to be deliv¬ 
ered atomically. If any participant receives 
a group message, other members in the 
group should also receive that message 
within a bounded period. However, for 
each message delivered, the sender may 
receive replies from recipients, either in 
the form of private one-to-one correspon¬ 
dence or as follow-up discussions to all 
conference participants. In a follow-up 
message m , the speaker makes a point on 
the basis of all the messages related to m 
that he or she has received; these messages 


are called the context associated with m. 
For other participants to understand m 
properly, they must be able to reference its 
context. 7 A recipient should not see a 
message without having also received its 
context. This dependent relationship is 
sometimes called a causal relationship 2 
and defines a partial ordering among mes¬ 
sages submitted to a conference. 

In both distribution lists and confer¬ 
encing, absolute ordering is not required. 
Concurrent messages usually can be deliv¬ 
ered in arbitrary order because they are not 
context related and because the partici¬ 
pants’ states are not message dependent. 
When necessary, the conference chair de¬ 
termines the order of concurrent messages. 
Sending and receiving messages can be 
concurrent and asynchronous for each 
participant. Because incoming messages 
may affect the content of outgoing ones, 
receiving may be given higher priority than 
transmission. 

In conferencing, a follow-up message 
may become a competitive orphan (ex¬ 
plained later) because of the asynchronous 
nature of the communication pattern. In 
this situation several people may respond 
identically to the same message before 
seeing each other’s responses. Fast deliv¬ 
ery makes this problem less likely but does 
not eliminate it entirely. 

Membership changes should not affect 
group communications. A new member 
normally becomes up to date by reading 
the conference bulletin board or the discus¬ 
sion archive. The failure of a member is 
normally treated as departure from the 
group. 

Distributed databases. A deterministic 
Het group can be used within a distributed 
database. A distributed database model has 
a transaction manager (TM) and a data 
manager (DM) on each site. Each TM 
accepts user requests and translates them 
into commands for DMs. Each DM main¬ 
tains part of the database stored at its site 
and may concurrently execute transactions 
from multiple TMs. A transaction group 
consists of all DMs participating in the 
same transaction. This group is heteroge¬ 
neous because each DM maintains a differ¬ 
ent part of the database and each may 
respond differently (accept or reject the 
precommit from the TM) according to its 
local status. Messages from the coordinat¬ 
ing TM are delivered atomically to the 
transaction group. 

For concurrency control and failure 
recovery, a two-phase commit protocol 
(2PC) is normally used at the end of each 
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transaction. When the coordinating TM 
and all cohorts (DMs) that know the deci¬ 
sion (commit or abort) fail, the standard 
2PC will be blocked until some processes 
recover. A simple nonblocking 2PC can be 
designed on the basis of ordered atomic 
group communication. 3 

In the absence of a coordinating TM 
failure, the protocol proceeds as the nor¬ 
mal 2PC. When the coordinating TM fails, 
a communication-layer-generated failure 
notification is broadcast to the group, and 
upon receiving this notice each DM aborts 
the transaction. This protocol requires not 
only an atomic but also an ordered group 
communication mechanism to guarantee 

(1) that every DM in a transaction group 
will receive exactly the same sequence of 
instructions from the coordinating TM, 
and (2) that if the coordinating TM fails 
after broadcasting commit, its failure noti¬ 
fication is delivered either before or after 
its commit message consistently and at¬ 
omically to all DMs, allowing them to 
either commit or abort the transaction 
consistently. Although the membership of 
a transaction group is governed by the 
coordinating TM, and a DM failure is de¬ 
tected by the TM during the execution of 
2PC, the communication layer still needs 
this information to achieve atomicity. In¬ 
consistent replies from DMs are handled 
by the coordinating TM itself rather than 
by the group mechanism. 

Summary of requirements. The above 
analysis of deterministic group applica¬ 
tions makes clear that group transparency 
is a desirable property allowing a client to 
treat a group’s service as if it were pro¬ 
vided by a single server. A single call is 
made and a single result, if any, is expected 
from the server group. Also, a server main¬ 
taining group object replicas need not 
know that another coserver exists, and thus 
application programmers need not be 
aware of group coordination. 

Group transparency for deterministic 
groups must satisfy the following require- 

(1) Communication transparency. 
Communication transparency consists of 
two aspects: atomicity and ordering. 2 

• Atomic message delivery. An atomic 
group message is either received and pro¬ 
cessed exactly once by all members in the 
recipient group, or by none at all. Atomi¬ 
city hides a partial group communication 
failure by converting it into a total failure. 

• Application-level absolute ordering. 


In both distribution 
lists and conferencing, 
absolute ordering 
is not required. 


The delivery order of messages to group 
members needs to be synchronized if the 
order will affect the result. Every member 
of a group must see the same sequence of 
requests on dependent data and adjust its 
internal state accordingly. Also, in the case 
of colliding requests, the common mem¬ 
bers of two overlapping groups must see a 
consistent “combined” sequence of re¬ 
quests to both groups. 

(2) Reply-handling transparency. Be¬ 
cause client and server interactions nor¬ 
mally follow the request-response pattern, 
reliable multicast from client to server is 
not enough. Replies from a group also 
must be collected and processed properly 
to achieve group transparency. 2 - 4 For each 
group request, there exists a potential for 
multiple responses from a server group. 
These responses may or may not be identi¬ 
cal. Reply-handling transparency guaran¬ 
tees that a client need not be aware of the 
multiple replies to its request. It sees a 
single reply without having to be con¬ 
cerned about how this reply is derived 
from others (for example, by weighted 
voting). 

(3) Naming transparency. This in¬ 
volves dynamically and transparently 
binding group members to a single name. 
Group naming consists of two parts: map¬ 
ping a logical service name into a group of 
servers, and allowing group membership 
to change dynamically. A group view is a 
snapshot of the group membership at a 
particular instant in time. It is maintained 
by each of the concerned parties, be they 
group members, system name servers, or 
any client needing to make decisions on 
the basis of the group view. A group view 
changes as members fail and recover, or 
are inserted and deleted, in parallel with 
other group message activities. 

Since atomic group interactions rely on 
a consistent group view to verify that all 
active members have confirmed reception 
of each atomic message, group view 


changes must be detected in a consistent 
manner. It is convenient to serialize group 
view changes consistently with respect to 
other group message activities. Isis group 
members achieve this by having a system- 
generated announcement, issued on behalf 
of the failed member, follow all its prefail¬ 
ure messages. This announcement arrives 
at every member in the same order with 
respect to the other group messages, so that 
members all see the same sequence of 
group view transitions at virtually the same 
time. Therefore, it is guaranteed that no 
message will arrive from a failed member 
once its failure has been announced. 2 If a 
member recovers, its state must be brought 
up to date with a consistent snapshot of the 
group’s internal state, and all concerned 
parties should perceive the new member’s 
existence before receiving a message from 
it. 

(4) Failure transparency. Depending 
on a group’s purpose, either clients and 
server group members are notified of the 
failure to take application-level recovery 
actions, or a member failure is hidden from 
the clients. In the latter case, the failure 
may be presented as a complete group 
failure, or other group members may take 
over the role of the failed member. The 
technique chosen depends on the group’s 
function. When a deterministic group is 
used to enhance data reliability, as in rep¬ 
licated file systems or databases, strong 
consistency is required among the group 
object replicas. Therefore, the group con¬ 
sistency control strategy may exaggerate a 
partial failure as total; if any member fails 
or the network is partitioned during a group 
operation execution, the operation cannot 
succeed until the failure is recovered or the 
group is properly reconfigured. However, 
when a group is used to enhance service 
reliability, as in a replicated procedure, 
call, maintaining service to clients is im¬ 
portant. During recovery of the failed 
member, remaining active group members 
should continue fulfilling their duties to 
keep damage to a minimum. 

(5) Real-time requirement. We can 
measure multicast message delay in terms 
of distribution time — the time taken for 
all operational members in a group to re¬ 
ceive a multicast — or in terms of comple¬ 
tion time — the time taken for the sender to 
learn that all destinations have received its 
message reliably. 8 In deterministic group 
applications, consistency is more impor¬ 
tant than efficiency. When trade-offs be¬ 
tween the two are required, system support 
often gives priority to consistency. In real¬ 
time systems, on the other hand, messages 
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usually must be delivered within a client- 
specified deadline; otherwise, a message is 
deemed obsolete and a timing fault is trig¬ 
gered. 

In one-to-one interprocess communica¬ 
tions, a server can simply ignore a timing- 
fault message or respond to the client with 
an operation failure. In multicast, some 
servers may receive the message on time 
while others see a timing fault, even though 
atomicity and ordering are guaranteed. 
When this occurs, servers in the recipient 
group must coordinate to act consistently 
on each timing-fault message to guarantee 
consistency. Multicast distribution time 
should be bounded so that group actions 
can be scheduled to occur atomically and 
simultaneously in virtual time at all group 
members. 13 

Nondeterministic groups. Determinis¬ 
tic groups require strong data and behavior 
consistency, and synchronization among 
all members. Nondeterministic groups 
assume that their applications do not need 
such strong built-in consistency, and they 
relax it in various application-specific 
manners. Nondeterministic group mem¬ 
bers generally are not equivalent. 4 Each 
member may respond differently to a group 
request, or not respond at all, depending on 
the individual member’s state and func¬ 
tion. Normally, either member states of a 
nondeterministic group are unaffected by 
processing user requests, or they are not 
necessarily consistent. Either requests to 
such a group do not require all group 
members to act, or missing requests can be 
detected and recovery completed within 
the application. 

Because of the relaxed consistency, 
maintenance overhead for the group is 
generally lower than for a deterministic 
group. Whether a group should be imple¬ 
mented as deterministic or not depends on 
the application requirements. 

Next we will describe some nondeter¬ 
ministic group applications in terms of 
their basic characteristics and communica¬ 
tion requirements. 

Distributed clock service. The time-of- 
day service in the V system exemplifies a 
nondeterministic DOH group, 11 in which 
all group members implement the same set 
of functions and play the same role in the 
service. Although all members are sup¬ 
posed to maintain identical objects, the 
state of these objects may differ when a 
partial group communication failure re¬ 
sults in some members not receiving a 
group request. 


-:- 

I 

Failure of any 
name server does 
not stop activity at 
other servers. 


In the distributed time-of-day service, 
every station periodically receives a clock 
tick from a central clock. Between clock 
ticks, each machine’s clock replica simply 
caches the latest time stamp from the cen¬ 
tral clock and extrapolates forward using 
its local clock. Clock drifting can be cor¬ 
rected by the next clock tick. Time requests 
are handled using the locally extrapolated 
time values. Should any clock update 
message be missed, the next clock update 
corrects it. Although the time value stored 
in the local clock may not be absolutely 
correct, it is accurate enough for most non¬ 
time-critical applications. 

Similarly, many applications that repli¬ 
cate data do not require absolute consis¬ 
tency. The required level of consistency is 
obtained by using application semantic 
knowledge and assuming that the client 
can detect, recover from, or tolerate incon¬ 
sistencies. This reduces communication 
complexity and promotes efficiency. The 
nondeterminism in these applications 
stems from the fact that group members 
may maintain an inconsistent or inaccurate 
global group state. Applications of this 
type need only an efficient and “best ef¬ 
fort” multicast mechanism. 

Distributed name service. In a distrib¬ 
uted name service, a set of name servers 
operate at several machines in the network. 
In some designs the global name space is 
partitioned, and a different name server 
maintains each partition. 10 This type of 
distributed name server forms a nondeter¬ 
ministic OHO group, because every mem¬ 
ber performs the same set of operations. As 
an example, each object in the operating 
system Clouds 10 is assigned a logical sys¬ 
tem name. A mapping function w maps a 
system name onto a multicast address A = 
w ( S ). Each station maintains a multicast 
address table for the objects stored at the 
node. To locate an object O, a user pro¬ 
vides its system name S. The client host 


first calculates O’s multicast address A = 
w (S) and uses A as an index to search its 
local object directory. If the object is not 
found, a multicast remote procedure call is 
invoked on the address A. Nodes with A in 
their multicast address table accept the 
remote procedure call, search the local 
object directory for the object with the 
system name 5, and reply if they find it. In 
this way, all nodes share the overhead of 
maintaining, locating, and migrating ob¬ 
jects. 

Group transparency is an important 
property expected by both clients and serv¬ 
ers. A client locates an object by submit¬ 
ting a name look-up request to the name 
service. It is irrelevant to the client which 
server responds or whether single or mul¬ 
tiple servers handle the request. Each 
server manages its assigned portion of the 
name space and responds only to requests 
for objects it knows. It need not be aware 
that other servers exist. 

Nondeterminism in distributed object 
naming results from the global group 
state’s being partitioned among members; 
therefore, a client does not know which 
server will perform its request. A LookUp 
need not be multicast to name servers at¬ 
omically, because it is an idempotent op¬ 
eration and does not alter the name servers ’ 
state. Note, however, that the name-bind¬ 
ing update in the name servers is a deter¬ 
ministic operation, and all replicated serv¬ 
ers, if any, must execute the update opera¬ 
tions atomically and in the same order in 
which names are bound. 

Grapevine 12 adopted another way of 
supporting a distributed name service. It 
exemplifies the nondeterministic DHO 
group in which the name space is fully 
replicated at each name server. However, a 
server may play primary or secondary roles 
in name updates, even though every server 
supports the same set of operations. The 
Grapevine update algorithm does not guar¬ 
antee a consistent view at all name repli¬ 
cas, because name update broadcasts are 
neither atomic nor ordered. A client deals 
only with its local name server without 
seeing the whole name server group. 
Clients can detect and correct inconsistent 
and stale names in an application-specific 
manner. 

Both examples should make clear that 
failure of any name server does not stop 
activity at other servers. 

Contract bidding. Contract bidding, 
another example of the nondeterministic 
OHO group, is a technique for resource 
sharing and load balancing among stations 
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in a server pool. Clients submit job re¬ 
quests for servers to complete. The spe¬ 
cific server station and the order of execu¬ 
tion do not matter. Server group members 
do not maintain a global group state. All 
worker stations are functionally identical 
and respond to idempotent service contract 
bids only on the basis of their local state. 
Upon completing a task, servers return to 
the ready state for the next job assignment. 

The number of available server stations 
is always changing, as is their current load. 
To optimize overall system throughput and 
mean response time, tasks should be sched¬ 
uled to keep all servers equally busy. 
Scheduling is usually done in one of two 
ways: In a client-initiated scheme, a client 
posts its task requirement on the network 
for server stations in the pool to bid on. An 
available server responds with its current 
load condition, and the client chooses the 
proper server to complete the task. In a 
server-initiated scheme, potential clients 
form a group, and an available server posts 
its request for loading to the client group. 
Each client responds with its task requests, 
and the server chooses the appropriate one 
to execute. 

In both schemes a competitive orphan 
may be generated. In contrast to & failure 
orphan, generated when a server continues 
to execute a dead client’s request, a com¬ 
petitive orphan is generated when server 
group members are not properly coordi¬ 
nated. (Failure orphans are a general prob¬ 
lem in the client-server model, while 
competitive orphans are a special problem 
in the group communications context. We 
can view a failure orphan as resulting from 
a lack of coordination between the client 
and the server group^we can view a com¬ 
petitive orphan as resulting from a lack of 
coordination among group members.) 

In the server-initiated scheme, a com¬ 
petitive-orphan request could be generated 
from a client that does not know whether 
its job request has already been carried out. 
Also, in the client-initiated scheme, multi¬ 
casting a job request could trigger multiple 
concurrent executions at different servers, 
even when only a single execution is 
needed. The effect of competitive orphans 
must be cancelled or reduced to a mini¬ 
mum, and the competition losers must be 
notified so that they can participate in 
subsequent contract-bidding activities. 
Again, communication overhead between 
clients and server group members should 
be minimized; multicast should be effi¬ 
cient but need not be perfectly reliable. 
The failure of any server should not termi¬ 
nate the whole system. However, the client 
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The dominant 
communication pattern 
in nondeterministic 
group applications is 
request-response. 


whose job was being executed by the failed 
server must be notified to resubmit its 
request. 

News propagation. News propagation 
in Usenet exemplifies the nondeterminis¬ 
tic Het group. People subscribing to the 
same news group constitute a group, and 
the state and operations each subscriber 
performs differ. A news poster never 
knows who the members in a group are. 
News propagations need be neither atomic 
nor ordered. Respondents to a news article 
can use one-to-one personal correspon¬ 
dence or follow-up articles to the same or 
a different group. Each person then de¬ 
cides what to do with each news article and 
the follow-up comments. A subscriber can 
come and go at will; no synchronization is 
necessary. 

Summary of requirements. Nondeter¬ 
ministic groups are intended to improve 
service performance. Through group trans¬ 
parency, a group service strives for the 
same simple syntax and semantics found in 
one-to-one interprocess communication. 
However, depending on the intended ap¬ 
plications and the nature of the particular 
group, this transparency may be relaxed. 
Nondeterministic groups induce less over¬ 
head and generally have the following 
characteristics and requirements: 

(1) Communication transparency. The 
dominant communication pattern in non¬ 
deterministic group applications is re¬ 
quest-response. Usually, applications do 
not require absolutely reliable message 
delivery or message ordering. Interactions 
with nondeterministic groups are inher¬ 
ently asynchronous because (1) it is nei¬ 
ther necessary nor realistic to expect a 
client to wait until all server group mem¬ 
bers are synchronized and ready to receive 
a request; (2) server group membership 


normally is not known to clients; and (3) a 
server may not receive the request at all. 
Data consistency is not a problem for vari¬ 
ous reasons: The application requests may 
be idempotent, group consistency may not 
be critical to the application, or the appli¬ 
cation may be able to detect and recover 
from inconsistency easily. Application 
programmers are given the flexibility — 
with the attendant complexity — of han¬ 
dling partial message failures. 

(2) Reply-handling transparency. Mul¬ 
tiple replies from a nondeterministic group 
may not be consistent. They may have to be 
handled by the clients in an application- 
specific manner rather than by the server 
group, as in deterministic groups; this 
sacrifices a certain degree of reply-han¬ 
dling transparency. Also, an application 
must provide its own time-out value for 
each multicast request because the com¬ 
munication layer itself does not know how 
long to wait for server group responses. 
When the timer expires, the application 
can decide whether to re-multicast or per¬ 
form alternative actions. In deterministic 
groups, these actions are normally per¬ 
formed at the communication layer. 

(3) Naming transparency. As with de¬ 
terministic groups, applications prefer to 
use a logical name to address a group 
service rather than having to know each 
individual member. To achieve naming 
transparency, both clients and servers pre¬ 
fer to handle requests and replies inde¬ 
pendently of the number of servers. How¬ 
ever, nondeterministic group membership 
can change dynamically and usually is not 
known to the active group members or to 
the communication layer. 

(4) Failure transparency. Nondeter¬ 
ministic group member failure has differ¬ 
ent semantics from that of deterministic 
groups. When a member fails, other active 
members may transparently take over the 
uncompleted task to enhance availability, 
share service load, and reduce global 
communication traffic. 

(5) Competitive-orphan problem. In a 
nondeterministic group a competitive or¬ 
phan can be generated because of a lack of 
internal coordination among group mem¬ 
bers. Except in computer conferencing, 
most deterministic groups do not experi¬ 
ence this problem, because a group request 
must be handled by every member syn¬ 
chronously while the client waits for a 
reply from every server. 

Table 1 shows the differences between 
deterministic and nondeterministic cate¬ 
gories. 
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Table 1. Differences between deterministic and nondeterministic categories. 



Deterministic 

Nondeterministic 

Communication 

Normally requires atomicity and absolute 
ordering. Some applications require causal ordering. 

Not necessarily reliable, nor ordered. 

Applications handle inconsistency. 

Naming 

Complete group view at communication layer 
is necessary. Membership changes must be 
synchronized with all other group messages. 

Group view usually is not known to anyone, 
even to the communication layer. 

Reply handling 

If required, expect all members to reply. 

Group members handle inconsistent replies 
without the client’s being involved. 

Clients must handle inconsistent replies 
explicitly and applications have to provide 
the time-out parameter. 

Failure handling 

To enhance reliability, a partial failure 
is turned into a total failure in most cases. 

To enhance availability, partial failures 
are usually hidden by active group members. 

Others 

In real-time systems, a timing fault 
may cause inconsistency. 

A competitive orphan may arise due to a lack 
of proper coordination among group members. 


Table 2. Sample applications based on the classifications. 



Deterministic 

Nondeterministic 

Data and operation 
homogeneous (DOH) 

Fully replicated file systems (peer-member 
scheme) and replicated procedure call. 

Applications such as the distributed 
time-of-day service in the V system. 

Operation homogeneous 
only (OHO) 

Partially replicated file systems. 

Clouds’ distributed name-server group 
and contract bidding. 

Data homogeneous 
only (DHO) 

Fully replicated file systems (primary 
and secondary scheme). 

Grapevine’s name-server group. 

Heterogeneous (Het) 

Distributed process control, computer 
conferencing, and E-mail distribution list. 

News propagation in a news group 
of Usenet. 


Discussion 

Several existing systems support group 
communications. The Isis 2 and Circus 4 
systems are intended primarily for deter¬ 
ministic replicated data objects or proce¬ 
dure module groups. Birman and Joseph 2 
provide detailed design and analysis on 
protocols for atomic and ordered gfoup 
communications. The V system 1 '" and 
several other experimental systems 5 sup¬ 
port nondeterministic groups. 

The two classifications of groups previ¬ 
ously discussed are based on different cri¬ 
teria, one on structure, the other on behav¬ 


ior. By orthogonally projecting one over 
the other, as Table 2 shows, we hope to 
better understand how various group appli¬ 
cations fit the classifications. 

First, we can see that external uncertain¬ 
ties in most nondeterministic groups stem 
from the following facts: (1) objects are 
distributed only to a subset of group 
members, and the size and membership of 
this subset may not be known in advance; 
and (2) even when objects are fully distrib¬ 
uted to all group members, applications do 
not require their values to be always con¬ 
sistent or accurate, and missing group 
messages can be tolerated. 


Second, Table 2 shows that most deter¬ 
ministic group applications require mes¬ 
sages to be sent atomically and in order, 
regardless of the homogeneity of group 
structure. Also notice that communication 
support for a deterministic DHO group is 
the same as for a deterministic DOH group. 
No matter how differently each individual 
DHO group member functions at the high 
level, to guarantee consistency among 
replicas, changes to the objects must be 
propagated atomically and in order. 

Let’s consider partially replicated file 
systems as an example of the deterministic 
OHO group in Table 2. File system relia- 
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bility requires that for each update request, 
only those servers having the target file 
take action and respond. It is difficult to 
map a logical file onto an unknown number 
of file servers maintaining the physical 
replicas of the file. Thus there exists a level 
of inherent nondeterminism in the group 
communication. If we had a separate server 
group for each replicated logical file ob¬ 
ject, we would end up with a fully repli¬ 
cated deterministic DHO server group for 
each file. However, this may not be neces¬ 
sary, and having many dynamically chang¬ 
ing groups could be expensive. 

It would be preferable to install software 
filters at the client and the servers to elimi¬ 
nate this structural nondeterminism. Each 
server filter would discard requests for 
nonlocal files. The client filter would use 
some mechanism (perhaps by consulting a 
name server) to determine the membership 
of the implied subgroup — those having a 
copy of the target file — and to guarantee 
atomic message transaction with only this 
subgroup. Once the implied subgroup 
membership was determined, the group 
transaction could proceed atomically. 

An alternative would be to have every 
file server reply to every request; those not 
knowing the target file would simply reply 
with a “null” message. The client would 
work on non-null replies using knowledge 
of the whole file server group membership 
to eliminate the above nondeterminism. 
This scheme trades extra host loading cost 
for structural determinism to gain reliabil¬ 
ity. It differs from broadcast in that (1) 
only file servers pay host-loading cost for 
each file access, and (2) as a system pro¬ 
gram, file servers are generally more 
trustworthy, and therefore file transactions 
can be made more secure. 


B efore designing a general, coher¬ 
ent, and integrated group commu¬ 
nication system, we must under¬ 
stand how it will be used, that is, the basic 
application requirements. We analyzed 
different types of groups, along with their 
potential applications, and classified group 
applications into two major categories: de¬ 
terministic and nondeterministic. Orthog¬ 
onally, according to the structure, process 
groups can also be classified as data opera¬ 
tion homogeneous, operation homogene¬ 


ous only, data homogeneous only, or 
heterogeneous. 

A basic conclusion from this analysis is 
that group transparency is important and 
desirable. When integrated into the under¬ 
lying group support, it simplifies the inter¬ 
face between server groups and their 
clients by hiding from the clients, as much 
as possible, the membership of server 
groups and the interactions among group 
members. This enables designers of clients 
and servers to concentrate on the problems 
to be solved — as they do in the unicast 
environment — without concern for coor¬ 
dinating multiple servers. Group transpar¬ 
ency is manifested in group communica¬ 
tion, group naming, multiple-reply han¬ 
dling, group view change, and partial fail¬ 
ure. 

We hope this classification framework 
and analysis will enhance the understand¬ 
ing of process groups, group communi¬ 
cations, and some applications, thus aid¬ 
ing designers working with these 
mechanisms.■ 
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Introducing TurboCASE™, the fastest, 
most integrated Macintosh CASE tool. 


StructSoft, Inc., the developerof one of the top selling 
PC CASE tools, now marketed as Teamwork/PCS A™ 
by Cadre Technologies, Inc., is proudly announcing 
a second generation CASE tool, TurboCASE, for the 
Apple Macintosh. 


TurboCASE is an integrated, multi-window, multi¬ 
methodology supporting CASE tool. It is extremely 
easy to learn and use. It supports Structured Analy¬ 
sis with or without the Real-Time extension. It will 
also support Data Modeling, Structured Design and 
Object Oriented Analysis and Design in the future. 


TurboCASE generates ASCII information exchange 
formats which can be used to link with Teamwork and 
Iconix' PowerTool™ 


A demo diskette is available for $15.00. 


StructSoft, Inc. 5416 156th Ave. SE, Bellevue, WA 98006. Tel: 206-644-9834 Fax: 206-644-7714 

Trademarks: TurboCASE : StructSoft, Inc.; Teamwork, Teamwork/PCSA : Cadre Technologies, Inc.; PowerTool: Iconix. 
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CALL FOR PAPERS AND PARTICIPATION 


Sixth Annual Computer Security 
Applications Conference 

December 3-7, 1990 
Tucson, Arizona 


The Conference 

Operational requirements for civil, military, and commercial systems increasingly stress the 
necessity for information to be readily accessible. The Computer Security Act of 1987 requires that all 
Federal agencies take certain actions to improve the security and privacy provided by federal computer 
systems. Accomplishing both operational and security requirements requires the application of the 
maturing technology of integrated information security to new and existing systems throughout their life 

CyCG This conference will explore technology applications for both civil and military systems; the 
hardware and software tools and techniques being developed to satisfy system requirements; and 
specific examples of systems applications and implementations. Security policy issues and standards 
will also be covered during this five day conference. 

Papers, Tutorials, and Vendor Exhibits 

Technical papers and tutorials that address the application of integrated information security 
technologies in the civil, defense, and commercial environments are solicited. Original research, analyses 
and approaches for defining the computer security issues and problems identified in the Conference’s 
interest areas; secure systems in use or development; methodological approaches for analyzing the 
scope and nature of integrated information security issues; and potential solutions are of particular 
interest. We are also interested in vendor presentations of state-of-the-art information security products. 
In addition, vendors of information security products are encouraged to exhibit at the conference. 


INSTRUCTIONS TO AUTHORS: 

Send five copies of your paper or panel proposal to Dr. Ronald Gove, Program Chairman, at the 
address given below. Tutorial proposals should be sent to Dr. Dixie Baker at the address given below. 
We provide blind refereeing; put names and affiliations of authors on a separate cover page only. It is a 
condition of acceptance that manuscripts submitted have not been published. Papers that have been 
accepted for presentation at other conferences should not be submitted. 

Papers and tutorial proposals must be received by May 18, 1990. Authors will be required to 
certify prior to June 20, 1990, that any and all necessary clearances for publication have been obtained, 
that they will attend the conference to deliver the paper, and that the paper has not been accepted 
elsewhere. Authors will be notified of acceptance by July 30, 1990. Camera ready copies are due not 
later than September 19, 1990. Material should be sent to: 


Dr. Ronald A. Gove 
Technical Program Chair 
Booz-Allen & Hamilton Inc. 
4330 East-West Highway 
Bethesda, MD 20814 
(301) 951-2395 
Gove@dockmaster.ncsc.mil 


Dr. Dixie B. Baker 
Tutorial Program Chair 
The Aerospace Corporation 
P.O. Box 92957, Ml/005 
Los Angeles, CA 90009 
(213) 336-7998 
baker@aerospace.aero.org 


Mr. Robert D. Kovach 
Exhibits Chair 

6946 33rd Street N.W. 

Washington, D.C. 20015 
(202) 453-1182 

rkovach%nasamail@ames.nasa.gov 


Areas of Interest Include: 

ISO/OSI Security Architecture 
Advanced Architectures 
Trusted DBMSs and Operating 
Systems 

Current and Future Trusted 
System Technology 


Policy and Management Issues 
SDNS 

Risk/Threat Assessments 
Network Security 
State-of-the-Art 
Trusted Products 


GOSIP 

C 3 I Systems 

Public Law 100-235 

Medical Records Security 

Space Station Requirements 

Certification, Evaluation, and Accreditation 


Reviewers and Prospective Conference Committee Members 

Anyone interested in participating as a reviewer of the submitted papers, please contact Dr. Ron 
Gove at the address given above. Those interested in becoming members of the conference committee 
should contact Dr. Marshall Abrams at the address below. 


Additional Information 

For more information or to receive future mailings, please contact the following at: 


The MITRE Corporation 
7525 Colshire Drive 
McLean, VA 22102 


Marshall Abrams 
Conference Chairman 
(703) 883-6938 
abrams@mitre.org 


Diana Akers or Victoria Ashby 
Publicity and Publication Chairs 
(703) 883-5907 or (703) 883-6368 
akers%smiley@gateway.mitre.org 
ashby%smiley@gateway.mitre.org 




ISMM 



CALL FOR PAPERS 



ISMM International Conference 



PARALLEL AND DISTRIBUTED 
COMPUTING, AND SYSTEMS 



October 10-12,1990 

New York, U.S.A. 



SPONSOR 

The International Society for Mini and Microcomputers-ISMM. 
Technical Committee on Computers. 


SCOPE 

. Architecture 
. VLSI 

• Software 

. Language 

• Compilers 

• Algorithms 
. Analysis 

. Design 


■ Intelligent and knowledge-based systems 
' Expert systems 

> Software engineering 

■ Scheduling 
Partitioning 
Communication 
Queueing 
Reliability 


INTERNATIONAL PROGRAM COMMITTEE 


N. A. Alexandridis U.S.A. 
R. Ammar U.S.A. 

B. Furht U.S.A. 

K. Huang U.S.A. 

J.L. Houle Canada 


SUBMISSION OF PAPERS 


L. Jamieson U.S.A. 

E. Luque Spain 

L. Miller U.S.A. 

P. Markenscoff U.S.A. 

G. Mastronardi Italy 


LOCATION 

New York Penta Hotel. 


• Fault-tolerance 

• Supercomputing 
. Neural networks 

. Optical computing 

• Others 

. Applications (all areas). 


A. Osorio-Sainz France 
H. Sholl U.S.A. 

S. Stolfo U.S.A. 

C.L. Wu U.S.A. 


April 2, 1990 
April 2, 1990 
May 10,1990 
July 1, 1990 


Three copies of manuscript (maximum ten pages) 

Three copies of 300 word abstract for short papers (maximum five pages) 
Notification 

Papers are in camera-ready form together with preregistration 


Expanded papers for a special issue on distributed and parallel systems are to be sent directly to the Editor, 
Dr. B. Furht, Modcomp, 1650 West McNab Road, P.O. Box 6099, Mail Stop 850, Ft. Lauderdale, FL 
33340-6099, U.S.A. 


ADDRESS 

For submission of papers or abstracts, and to be placed on the mailing list write to : Dr. R.Ammar, PDCS'90 
U155, Computer Science and Engineering Department, University of Connecticut, Storrs, CT 06268, U.S.A. 
Fax: (203) 486-0318 









STANDARDS 


Editor: Fletcher J. Buckley, 103 Wexford Dr., Cherry Hill, NJ 08003, phone (609) 866-6350, fax (609) 866-6289, Compmaib f.buckley 


Applications environment profiles 

A significant tool for simplifying and coordinating standards efforts 

Jim Isaak, Digital Equipment Corporation, and Chair, Standards Subcommittee, IEEE 
Computer Society Technical Committee on Operating Systems and Operating Environments 


The proliferation of standards and the 
need to integrate them has created a night¬ 
mare for software developers. To effec¬ 
tively use standards, developers identify 
the ones they need and determine the vari¬ 
ations within them they can use or want to 

On the surface, this forces developers 
to become “experts” in standards, if they 
want to use them, or to rely on vendor 
documentation where the value-added 
and standards components are not differ¬ 
entiated. Moreover, for developers who 
gain expertise, the gaps between the stan¬ 
dards become evident, reducing their 
ability to attain the portability and inter¬ 
operability benefits of the standards. 

Applications environment profiles 
provide a tool for attacking both of these 
issues, first, in simplifying the task of 
identifying relevant standards and the 
applicable options, and second, in identi¬ 
fying the gaps and providing a mecha¬ 
nism to complete the array of standards in 
a coherent manner. 

A portable application must rely on 
many different standards. One type is the 
language standard, since it defines the 
basic set of services and the style of pro¬ 
gramming. Early on, languages were tar¬ 
geted at specific applications domains, 
Fortran for math and Cobol for commer¬ 
cial applications. 

Today, applications service standards 
like SQL (relational database) and GKS 
(Graphics Kernel System) are being de¬ 
veloped that have interfaces to multiple 
languages. The applications program 
interfaces (APIs) to these services aug¬ 
ment the capabilities in the languages to 
provide a rich programming environ¬ 
ment. 

To help us identify these additional 
types of standards, let me suggest the 
terms base service for the language-inde¬ 


pendent semantics and language bind¬ 
ings for the language-specific APIs. 

Even within focused base service efforts, 
various requirements and industry con¬ 
siderations exist. These can result in mul¬ 
tiple similar standards or in options 
within a single standard. Options have 
gotten bad press as being a “concession to 
consensus,” but they may also reflect dif¬ 
fering requirements of different applica¬ 
tions domains. 

As we try to establish a comprehensive 
range of standards, we find that a new set 
of issues starts to emerge. Standards that 
fill the gap between existing projects nec¬ 
essarily have scope statements that over¬ 
lap the standards on either side. (For ex¬ 
ample, developing APIs for the Open 
Systems Interconnection Layer 7 file 
transfer and management service in the 
Posix domain touches both the OSI 
FTAM and various Posix projects.) So, 
we need coordination. Second, there is a 
rapid proliferation of such work, increas¬ 
ing the need for coordination and the 
number of standards. Finally, from a user 
perspective, there is an increasingly com¬ 
plex alphabet soup of standards and no 
way to clearly associate these with user 
needs. 

This leads to the focus on an additional 
type of standard: applications environ¬ 
ment profiles. Like OSI profile work, 
AEPs embrace a group of standards, to¬ 
gether with specific options within them, 
designed to fulfill specific functional 
needs. To understand how this might 
work, let’s start from the view of the ap¬ 
plications program. 

Application environment profiles 
from the application program view. An 

applications program needs certain ser¬ 
vices to operate. Many of these are stan¬ 
dardized, some are suitable for standardi¬ 


zation, and some may be very user/ven¬ 
dor or otherwise implementation spe¬ 
cific. These implementation-specific 
services impede portability but, with 
careful management, the portability im¬ 
pact can be minimized and at least limited 
to programs where it can be justified. Us¬ 
ers typically want to run a variety of pro¬ 
grams that are targeted within a specific 
domain. This might be a banking system, 
a CAD system, a small business system, 
etc. The programs for these domains tend 
to need a common set of services. 

From his or her perspective, the user 
needs a system that supports the 
domain(s) needed in terms of applica¬ 
tions. The standards component of this 
common set of services can be viewed as a 
profile, specifically an applications envi¬ 
ronment profile. AEPs are associated 
with specific functional areas of applica¬ 
tions, such as banking, CAD, or small 
business systems. 

An AEP needs to be complete with re¬ 
spect to its environment. That is, it should 
reference all of the standards required 
and speak to all of the options. Where an 
essential function does not exist, this 
needs to be identified and a course of ac¬ 
tion needs to be recommended. (See the 
comments below on the impact on base 
service standards.) 

A profile should also be coherent, that 
is, logically connected. Let’s consider an 
example that clarifies these terms. For a 
commercial application domain, it may 
be necessary to have Cobol, C, and SQL. 
For completeness, this profile would also 
need the bindings from SQL to Cobol and 
C. For coherence, Cobol and C can use 
SQL operations on the same files at the 
same time. Completeness refers to hav¬ 
ing all of the proper standards, whereas 
coherence refers to assuring the proper 
relationship between elements. 
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You may be surprised to hear that the 
same file can be manipulated by pro¬ 
grams in both languages (perhaps con¬ 
currently), but that is not implicit in any 
of the standards. Simply given the list of 
standards, obtaining two different SQL 
packages — one for Cobol and one for C 
— would be possible, and the two could 
not share files. This might be acceptable 
in some cases. In addition, a profile can be 
coherent by indicating that “no interac¬ 
tion” is required. 

Profiles become the focal point for 
specification, conformance testing, and 
applications development. A user can in¬ 
dicate which functions are needed on a 
given system, identify the applicable pro¬ 
files, and use these in a purchasing speci¬ 
fication. A systems vendor can indicate 
which profiles are offered and more 
clearly target applications areas with the 
vendors’ systems. Applications vendors 
(and developers) can focus on solving 
application problems, targeting their 
software for the proper applications envi¬ 
ronment. 

Assuring that profiles use common op¬ 
tions and selections when addressing 
common functional needs is required. 
This is called “harmonization” in the OSI 
world, and it applies here as well. Part of 
the charter for any group developing pro¬ 
files must be an understanding of the need 
for harmonization. 


Profiles as a standards development 
organizational tool. Profiles can greatly 
benefit and change the way we develop 
standards. First, a base service standard 
should be viewed as a menu to be used in 
profile development. This means that op¬ 
tions should be encouraged and the mo¬ 
tives for them documented. Profile 
groups will want to pick out what they 
need and leave behind what is not needed. 
In addition, profile groups might identify 
requirements for additional functional¬ 
ity. This should be accepted as a require¬ 
ment for work by the base service group 
so standards for this functionality can be 
developed in a way that is consistent and 
complementary to their existing work. 
The alternative is to have some other 
group develop that functionality — a 
strategy that can lead to a loss of consis¬ 
tency. Two profile groups can possibly 
request mutually exclusive functionality 
from a single standard. They could be 
provided as optional capabilities (docu¬ 
menting the mutual exclusion and mo¬ 
tives), and each could use the appropriate 
option in their profiles. 

Profiles may eliminate the need for lev¬ 
els of conformance within a base service 
standard. Historically, no other specifi¬ 
cation existed to define how to put the ele¬ 
ments of the standard together, and levels 


have been used to segment standards. 
This tends to be limited, since a level and 
module scheme that is too complex (for 
example, the early versions of Cobol) be¬ 
comes too difficult to assure portability. 
Since profiles specify the components 
and options, they can be used to eliminate 
the need for levels. For the user, the pro¬ 
file is the significant factor; if a vendor 
provides more, that is sufficient, but less 
is unacceptable. Harmonization will 
avoid needless profile variations. Select¬ 
ing by profile, system purchasers can 
avoid the overhead and costs of a system 
that provides more than is required. Simi¬ 
larly, applications developers can focus 
on a target environment that will be im¬ 
plemented on many systems. Finally, 
vendors can focus on niche markets with 
specialized systems that implement the 
requisite profiles. 

Profiles that include profiles are likely 
to occur as well. For instance, in the ex¬ 
ample given earlier, “banking” defines 
too broad a domain. The services needed 
in a loan department are quite different 
from those at an automated teller machine 
or some transaction-processing, elec¬ 
tronic-fund-transfer system. At the same 
time, all of these may need to interact with 
other types of distributed systems, and 
this could be addressed by common OSI 
profiles for interoperability. Since pro¬ 
files can be standardized, profiles for a 
large application domain, built from 
more focused standardized profiles, 
would be an appropriate use of this con¬ 
cept. 

In short, applications environment 
profiles provide the tool needed to con¬ 
vert the rapidly expanding array of stan¬ 
dards into useful quanta of services for 
users and applications developers. They 
can lead to closer coordination of the 
standards, eliminating duplication, in¬ 
consistency, and arbitrary segmentation 
of work. 

Two groups sponsored. The IEEE 
Computer Society Technical Committee 
on Operating Systems and Operating En¬ 
vironments (TCOS) is sponsoring two 
AEP standards groups. One, P1003.10, 
focuses on supercomputing applications; 
the other, PI003.11, focuses on transac¬ 
tion processing. These groups are both 
building on the standards developed by 
the 1003.X Posix groups, as well as other 
standards of the American National Stan¬ 
dards Institute and International Organi¬ 
zation for Standards. 

If you are interested in participating in 
the TCOS standards work in applications 
environment profiles, contact the stan¬ 
dards coordinator at the Computer Soci¬ 
ety’s office at 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 



US Memories folds 

US Memories, the proposed $1 billion 
consortium for revitalizing US produc¬ 
tion of DRAMs, is closing down due to a 
lack of financial backing. 

The decision was made at a meeting 
January 10 that included the original 
seven investing firms — Advanced Mi¬ 
cro Devices, Digital Equipment Corp., 
Hewlett-Packard, IBM, Intel, LSI Logic, 
and National Semiconductor — and four 
other potential investor companies — 
AT&T, Compaq, NCR, and Tandem 
Computers. 

The original seven investors would 
have provided $500 million of the needed 
funds, with the rest financed by loans. 
However, since the consortium was an¬ 
nounced in June 1989, no other investors 
have stepped forward. 

“The viability of US Memories was 
contingent upon our ability to obtain a 
significant amount of funding and pur¬ 
chase commitments from computer sys¬ 
tems companies,” stated Sanford Kane, 
US Memories president, in a prepared 
statement. “Everyone we approached 
embraced the concept of US Memories, 
but after six months of negotiations with 
individual firms ... it was clear that suffi¬ 
cient financial and output commitments 
would not materialize.” 

“The problem is our inability to work 
together and cooperate,” said Wilfred J. 
Corrigan, US Memories chair and chief 
executive officer of LSI Logic, at a press 
conference announcing the dissolution. 
“We are like an all-star team ... We don’t 
work together very well.” 

“The US has a national industrial pol¬ 
icy vacuum,” he said. 

The venture, which was designed to 
supply about 40 percent of the 4-Mbyte 
DRAM chips needed by US manufactur¬ 
ers, was initiated by the American Elec¬ 
tronics Association and the Semicon¬ 
ductor Industry Association. In its own 
statement, the AEA expressed disap¬ 
pointment. 

“Although DRAM availability and 
pricing is not currently a problem, our 
almost total dependence for this vital 
building block of both commercial and 
military electronics rests with foreign 
sources ... I feel certain that US DRAM 
re-entry efforts will not end here,” stated 
J. Richard Iverson, AEA president and 
chief executive officer. — S. Wilcox 
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Contributions to Update are welcome. Send news of industrial or university research and of public policy or professional issues to Update Editor, 10662 Los Vaqueros Circle, 
Los Alamitos, CA 90720, or to Editor-In-Chief Bruce D. Shriver, Vice President for Research, University of Southwestern Louisiana, Drawer 42730, Lafayette, LA 70504. 

Report: US must regain edge in consumer electronics 


Steve H. Wilcox, Staff Editor 

“The short-term orientation of US 
firms and their unwillingness to commit 
resources to the development and com¬ 
mercialization of new technologies is a 
critical factor in explaining the failure of 
US firms to compete in the fast changing 
electronics industry,” states a new report 
on the US consumer electronics market. 

The Consumer Electronics Industry 
and the Future of American Manufactur¬ 
ing cites barriers to US competitiveness 
in the global electronics market as well as 
several possible solutions, including the 
creation of a new “silicon culture.” 

The report was written by Susan Walsh 
Sanderson, associate professor in the 
School of Management at Rensselaer 
Polytechnic Institute, and was funded by 
a grant from the Ford Foundation. 

The problems. “Time is a competitive 
weapon in the global marketplace,” the 
report states. Among the primary barriers 
to US competitiveness in consumer elec¬ 
tronics are the typical US manufacturing 
process, the “safe haven” of military 
manufacturing, a focus on short-term 
profits, a lack of strategic alliances 
among companies, and a shortage of 
trained engineers, the report claims. 

Manufacturing. The report cites “the 
classical US manufacturing model, in 
which product development proceeded 
step-by-step through market analysis, 
product design, manufacturing, and 
sales,” and notes that “in the design cycle, 
US firms had traditionally focused on the 
features and performance of a new prod¬ 
uct rather than on the process by which it 
will be manufactured.” 

The report compares this approach 
with “simultaneous engineering” as 
practiced in Japan and elsewhere. This 
approach requires constant interaction 
among a company’s design, engineering, 
and production staffs. “The essence of 
the simultaneous engineering approach 
is to ‘get it right the first time,’ by tailor¬ 
ing design and manufacture to end uses.” 

Also, firms dealing in mature tech¬ 
nologies “must constantly upgrade their 
production methods, look for ways to cut 
costs and streamline production, while at 
the same time maintain quality and inno¬ 


vative technological improvements.” 

“Few American firms are willing to 
commit the level of engineering resources 
required by the Japanese approach to de- 
sign-for-manufacturability,” the report 
states. 

Military production. “For nearly a dec¬ 
ade, the nation’s budgetary priorities 
have emphasized greatly increased de¬ 
fense spending,” creating ‘“safe havens,’ 
where there is little international compe¬ 
tition, for US high-technology firms,” 
according to the report. 

“Defense procurement practices em¬ 
phasize design and production methods 
— low-volume, design redundancy, and 
high costs — that are not highly rewarded 
in the civilian marketplace," the report 
asserts. 

“If the US industrial base is to be im¬ 
proved, either resources will have to be 
shifted out of the DoD, or the DoD itself 
will have to play a direct role in shifting 
funds into programs that would directly 
improve the industrial base and capabili¬ 
ties of the nation.” 

Education. Problems cited here begin 
in elementary school with a shortage of 
mathematics and science teachers and 
continue through graduate school, where 
the problems cited above for military 
manufacturing are reinforced in research 
supported by “defense contracts or . . . 
government contracts with little empha¬ 
sis on production for the mass market.” 

The solutions. US firms must realign 
their design and manufacturing systems 
to allow rapid change and improvement, 
probably through simultaneous engi¬ 
neering, according to the report. The re¬ 
port also recommends shared manufac¬ 
turing among smaller firms, but acknowl¬ 
edges that “the legality of shared manu¬ 
facturing is a vast gray area” that might 
require changes in US antitrust laws. 

Government role. “Government has an 
important role to play in creating the ba¬ 
sic infrastructure for the entire technol¬ 
ogy base of the nation through support for 
education, including teaching factories 
and shared manufacturing facilities, and 


basic research and development,” the re¬ 
port states. 

Education. The report calls for the in¬ 
stitution of “teaching factories” that 
could “replicate the pressure of provid¬ 
ing high-quality/low-cost products in a 
timely fashion . . . Exposure to design, im¬ 
plementation, integration, and evalu¬ 
ation problems in real production set¬ 
tings may be the way to bridge the gap be¬ 
tween theoretical knowledge and its ap¬ 
plication.” 

The silicon culture. “A short turn¬ 
around time for prototyping the chips, in 
which the engineer can literally ‘try it in 
silicon,’ will be a prerequisite for com¬ 
mercial success,” the report states. 
“Building a silicon culture is the next 
challenge facing American business, and 
the success of electrical and electronics 
firms in the 1990s will depend upon 
building that culture today.” 

However, the report claims that few US 
firms have the “organizational and mana¬ 
gerial will” needed to implement such a 
culture, and that they lack “the ability to 
prototype systems components directly 
in silicon.” 

“The person who designs the algorithm 
... should have the ability to put the de¬ 
sign directly on a chip, test that chip, and 
modify the design. This requires a sepa¬ 
rate facility for quick turnaround of very 
small batches of chips as well as skilled 
programmers who could, at a minimum, 
run a CAD station and, with the aid of ex¬ 
pert systems design tools, design chips 
for systems applications.” 

The report states that the two obstacles 
to developing this culture are the lack of 
appropriate engineering skills and the ex¬ 
pense of operating such a facility. 

“Such facilities . . . must be undertaken 
for the contribution they make to the pro¬ 
duction of a wide variety of products 
within the firm. This goes against the 
grain of the short-term profit center ori¬ 
entation of American business.” 

Copies of the report are available for $8 
from the Economic Policy Institute, 1730 
Rhode Island Ave. NW, Suite 812, Wash¬ 
ington, DC 20036, Attn. Publications. 
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Editor: Guylaine M. Pollock, Sandia National Laboratories, 1424, PO Box 5800, Albuquerque, NM 87185; phone (505) 846-0040; electronic mail: gmpollo@sandia.gov. 


New IEEE fellows include 52 Computer Society members 


The IEEE Board of Directors has com¬ 
pleted its annual election for 1989 and 
conferred the title of IEEE fellow on 52 
Computer Society members. A total of 
422 nominations were made, from which 
230 were elected. The IEEE fellow desig¬ 
nation was effective as of January 1, 

1990. 

The title of fellow recognizes out¬ 
standing contributions of senior mem¬ 
bers in one or more areas. The alphabeti¬ 
cal list below identifies the new IEEE fel¬ 
lows who are Computer Society members 
and the citation each new fellow re¬ 
ceived. The IEEE society, group, or coun¬ 
cil that evaluated the respective candi¬ 
date appears in parentheses. 


Shojiro Asai, Tokyo, Japan, for contribu¬ 
tions to advancing semiconductor device tech¬ 
nology (Electron Devices). 

Victor R. Basili, College Park, Maryland, 
for contributions to software quality and pro¬ 
ductivity (Computer). 

Kenneth Brayer, Burlington, Massachu¬ 
setts, for contributions to fading channel data 
communications and error-correction coding 
techniques (Communications). 

Randal E. Bryant, Pittsburgh, Pennsylva¬ 
nia, for contributions to switch-level modeling 
of very large scale integrated circuits (Circuits 
and Systems). 

Chester C. Carroll, Tuscaloosa, Alabama, 
for leadership in electrical engineering educa¬ 
tion (Education). 

K. Mani Chandy, Austin, Texas, for contri¬ 
butions to queueing theory and its practical ap¬ 
plications to computer and communications 
systems (Computer). 

Basant R. Chawla, Allentown, Pennsylva¬ 
nia, for contributions to computer-aided de¬ 
sign of integrated circuits (Circuits and Sys- 


Alfred E. Dunlop, Murray Hill, New Jer¬ 
sey, for contributions to automated layout of 
integrated circuits and development of tech¬ 
niques that significantly enhance performance 
(Circuits and Systems). 

Mohamed E. El-Hawary, Halifax, Nova 
Scotia, Canada, for contributions to the theory 
of optimal economic operation of hydrother¬ 
mal power systems (Power Engineering). 

Eugene J. Fagan, Newark, Delaware, for 
contributions to and development of ground¬ 
ing for buildings and structures (Industry Ap¬ 
plications). 

Moustafa M. Fahmy, Kingston, Ontario, 
Canada, for contributions to the advancement 
of research in the area of multidimensional 
digital signal processing (Signal Processing). 

Michael J. Ferguson, Verdun, Quebec, 
Canada, for contributions to the performance 
evaluation of multiple-access data communi¬ 
cation networks (Communications). 

Wolfgang Fichtner, Zurich, Switzerland, 
for the application of numerical modeling to 
device scaling and submicron transistor opti¬ 
mization (Electron Devices). 

Thomas E. Fortmann, Cambridge, Massa¬ 
chusetts, for technical leadership in automated 
data analysis and multitarget tracking (Control 
Systems). 

Peter A. Franaszek, Yorktown Heights, 
New York, for contributions to the theory and 
practice of coding for constrained channels 
and digital magnetic recording (Computer). 

Samuel H. Fuller, Harvard, Massachusetts, 
for leadership and contributions to computer 
architecture design (Computer). 

Randall L. Geiger, College Station, Texas, 
for contributions to discrete and integrated 
analog circuit design (Circuits and Systems). 

Hiroshi Genchi, Tokyo, Japan, for contri¬ 
butions to the development and application of 
pattern recognition technology (Computer). 


Nicholas D. Georganas, Ottawa, Ontario, 
Canada, for leadership in university-industry 
research in, and performance evaluation of, 
multimedia communications networks and 
systems (Communications). 

Sakti P. Ghosh, San Jose, California, for 
contributions to database storage and retrieval 
(Computer). 

Ibrahim N. Hajj, Urbana, Illinois, for con¬ 
tributions to computer-aided simulation and 
design of very large scale integrated circuits 
and to engineering education (Circuits and 
Systems). 

C. Robert Hewes, Richardson, Texas, for 
leadership in the development of very large 
scale integrated circuit technology (Solid- 
State Circuits). 

Keki B. Irani, Ann Arbor, Michigan, for 
contributions to multiple computer systems 
(Computer). 

Sung Mo (Steve) Kang, Champaign, Illi- 
•nois, for technical contributions and leader¬ 
ship in the development of computer-aided de¬ 
sign of very large scale integrated circuits and 
systems (Circuits and Systems). 

Peter M. Kogge, Oswego, New York, for 
contributions to high-performance computing 
systems (Computer). 

P.S. Krishnaprasad, Glenn Dale, Mary¬ 
land, for contributions to geometric and non¬ 
linear control and to engineering education 
(Control Systems). 

Noriyoshi Kuroyanagi, Tokyo, Japan, for 
contributions to high-speed PCM and for tech¬ 
nical leadership in communications research 
(Communications). 

Robert B. McGhee, Monterey, California, 
for contributions to the theory and experimen¬ 
tal study of mobile robots and legged locomo¬ 
tion (Robotics and Automation). 

Umberto Mengali, Pisa, Italy, for contribu¬ 
tions to the theory of synchronization in digital 
communication systems (Communications). 
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Harlan D. Mills, Vero Beach, Florida, for 
contributions to the development of software 
methodologies and their transition into prac¬ 
tice (Computer). 

Salvatore D. Morgera, Montreal, Quebec, 
Canada, for contributions to finite-dimen¬ 
sional signal processing methods (Signal Pro¬ 
cessing). 

Joel Moses, Cambridge, Massachusetts, for 
leadership in the development of symbolic al¬ 
gebraic manipulation systems (Computer). 

Hussein T. Mouftah, Kingston, Ontario, 
Canada, for contributions to communications 
modeling (Communications). 

David R. Myers, Albuquerque, New Mex¬ 
ico, for pioneering the development of ion 
beam modification of strained-layer superlat¬ 
tice and quantum-well compound-semicon¬ 
ductor materials for novel electronic and opto¬ 
electronic devices (Electron Devices). 

David A. Patterson, Berkeley, California, 
for leadership in the development of reduced- 
instruction-set computers (Computer). 

Josef Raviv, Haifa, Israel, for contributions 
to data compaction, pattern recognition, and 
information theory (Computer). 

V. Thomas Rhyne, Austin, Texas, for con¬ 
tributions to the discipline of computer engi¬ 
neering and to computer engineering educa¬ 
tion (Education). 

Richard B. Robrock, II, Bedminster, New 
Jersey, for technical leadership in the architec¬ 
ture and implementation of the Intelligent Net¬ 
work (Communications). 

Mary M. Shaw, Pittsburgh, Pennsylvania, 
for contributions to computer science educa¬ 
tion (Computer). 

Isao Shirakawa, Osaka, Japan, for contri¬ 
butions to network theory and its applications 
to computer-aided circuit analysis and design 
(Circuits and Systems). 

Bruce D. Shriver, Lafayette, Louisiana, for 
contributions to computer organization and 
microprogramming (Computer). 

Howard J. Siegel, West Lafayette, Indiana, 
for contributions to the analysis and design of 
interconnection networks for highly parallel 
processors (Computer). 

Hiroshi Sugaya, Fukuoka, Japan, for con¬ 
tributions to magnetic video recording tech¬ 
nology and the establishment of international 
recording standards (Magnetics). 

Yasutsugu Takeda, Tokyo, Japan, for tech¬ 
nical leadership in optoelectronics, particu¬ 
larly in optical storage and recording (Lasers 
and Electro-Optics). 

Takeo Takemoto, Chiba-Ken, Japan, for 
technical leadership in development and pro¬ 
duction of color cathode ray tubes and other 
display devices (Electron Devices). 


Krishnaiyan Thulasiraman, Montreal, 
Quebec, Canada, for contributions to applica¬ 
tions of graph theory (Circuits and Systems). 

Iwao Toda, Kamagawa-Ken, Japan, for 
contributions to on-line computer systems, 
computer networks, and switching theory 
(Computer). 

Shigeo Tsujii, Tokyo, Japan, for contribu¬ 
tions to the development of digital signal pro¬ 
cessing in communication systems (Commu¬ 
nications). 

Raymond S. Turgel, Potomac, Maryland, 
for contributions to precision measurement 
techniques through development of analog- 
digital instrumentation (Instrumentation and 
Measurement). 

Jonathan S. Turner, St. Louis, Missouri, 
for contributions to multipoint switching net¬ 
works for high-speed packetized information 
transmission (Communications). 

Arend van Roggen, Kennett Square, Penn¬ 
sylvania, for the theoretical and practical de¬ 
scription of charge transport in dielectric mate¬ 
rials (Dielectrics and Electrical Insulation). 

Ronald Waxman, Reston, Virginia, for 
contributions to and leadership in the field of 
hardware description languages for computers 
(Computer). 


The Computer Society encourages 
members to help identify colleagues wor¬ 
thy of IEEE fellow recognition by initiat¬ 
ing the nomination process. A fellow 
nominee must 

• be an IEEE senior member; 

• demonstrate significant individual 
contribution(s) as an engineer or sci¬ 
entist, technical leader, or educator; 

• provide tangible and verifiable evi¬ 
dence of contribution(s); 

• have the Computer Society Fellows 
Committee’s endorsement; 

• receive confidential recommenda¬ 
tions by five other IEEE fellows; and 

• show evidence of IEEE service. 

The nominator facilitates a successful 
nomination by getting the necessary 
forms completed and sent to the IEEE 
Fellow Committee. A member wishing to 
nominate a worthy candidate should con¬ 
tact Michael C. Mulder, Center for Ad¬ 
vanced Computer Studies, University of 
Southwestern Louisiana, PO Box 44330, 
Lafayette, LA 70504, phone (318) 231- 
6147, e-mail mulder@usl.usl.edu, 
Compmail-t- m.mulder; or Tilak Ager- 
wala, IBM, 11400 Burnet Rd„ Austin, TX 
78758, phone (512) 823-6870. 

For additional information, see Com¬ 
puter, November 1989, pp. 71-72. 


Computer Society 
announces call for 
nominees, 1990 
election timetable 

The Nominations Committee of the 
IEEE Computer Society is inviting sug¬ 
gestions from the membership for Board 
of Governors nominees to serve terms 
starting January 1, 1991. Seven board 
seats will be filled during this fall’s mem¬ 
bership election, with the top vote-get¬ 
ters winning three-year terms. 

The Nominations Committee must re¬ 
ceive suggestions for Board of Gover¬ 
nors nominees by March 16, 1990. The 
suggestions must be accompanied by bio¬ 
graphical information and should in¬ 
clude facts about the nominee’s past or 
present participation in the society’s ac¬ 
tivities. These materials should be sent to 
Kenneth R. Anderson, Siemens Corpo¬ 
rate Research, 755 College Road East, 
Princeton, NJ 08540. 

Also in this year’s election, the mem¬ 
bership will select first and second vice 
presidents, who will serve in 1991, as 
well as the individual who will be the 
president-elect in 1991, president in 
1992, and past president in 1993. 

Election timetable. The following 
timetable for nominations and elections 
(for events following the committee’s 
March 16, 1990, nominations deadline) 
has been approved by the Board of Gover¬ 
nors. 

May 11 — Nominations Committee 
sends its slate of officer and board candi¬ 
dates to the Board of Governors. 

May 28 — Last day for submission of 
board/officer petition candidates’ peti¬ 
tions to the society’s secretary, David 
Pessel, BP Research, Sunbury Research 
Centre, Chertsey Road, Sunbury-on- 
Thames, Middlesex, TW16 7LN, Eng¬ 
land, fax 0932-762999, signed by mem¬ 
bers of the 1990 Board of Governors for 
additional nominees for the board and for 
officers. 

June 8 — Board and officer candidates 
selected at Board of Governors meeting 
at IEEE Infocom 90 in San Francisco. 

July — Computer publishes the board- 
approved slate of candidates and calls for 
additional petition candidates from the 
membership. (The process allowing 
members to nominate additional candi¬ 
dates by petition is described below.) 

July 6 — Position statements, biogra¬ 
phies, and photos of candidates selected 
by the Board ofGovemors are due at the 
society’s Los Alamitos office. 

July 31 — Petitions with candidates’ 
position statements, biographies, and 
photos are due at the office of the soci- 
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NEWS FROM THE COMMITTEE ON PUBLIC POLICY 

Action needed on computer ethics legislation 


ety’s secretary, David Pessel (see address 
above). 

September — Computer publishes po¬ 
sition statements, biographies, and pho¬ 
tos of the candidates. 

September 1 — Ballots are mailed to 
the membership. 

October 12 — Last day for receipt of 
marked ballots. 

December — Computer publishes 
election results. 

Petitioning nominations. Petitions to 
add nominees to the list of candidates pre¬ 
viously selected by the Board of Gover¬ 
nors for the board or for officers must 

• Set forth the office, the starting date 
of the office, and the name of the can¬ 
didate. 

• Contain, for board nominees, the sig¬ 
natures of at least 250 voting mem¬ 
bers of the society, with each member 
eligible to sign only one Board of 
Governors’ petition and, for officer 
nominees, the signatures of at least 

1,000 voting members of the society, 
with each member eligible to sign one 
petition for each office. Each signa¬ 
ture must be accompanied by the 
printed name of the signer. To avoid 
ambiguous identification of each 
signer, it is recommended (although 
not required) that the signer’s mem¬ 
bership number accompany his or her 
signature. 

• Be accompanied by a statement 
signed by the nominee that he or she is 
willing and available to serve, if 
elected. 

• Be received by Secretary Pessel on or 
before July 31, 1990. 

To qualify as a candidate for the board, 
a nominee must be a member of the soci¬ 
ety, must agree to seek significant in¬ 
volvement in society activities such as 
chairing a committee or serving as editor- 
in-chief or society representative, etc., 
and must meet other requirements as 
stated in the constitution and bylaws. 

To qualify as a candidate for an officer 
position, a nominee must hold a member 
grade or higher in the IEEE, must have 
been a Computer Society member for the 
preceding three years, and must meet 
other requirements as stated in the 
constitution and bylaws. 

Petitions can also be submitted to the 
secretary by Compmail+. To be counted 
as a signature on a Compmail+ petition, 
each person signing the petition by 
Compmail+ must originate a message 
stating his/her support of the nomination 
of the individual concerned and transmit 
it to Pessel. His Compmail+ ID is 
d.pessel. 


Ralph J. Preiss, COPP Chair 

In January, Robert Morris, Jr., went on 
trial for “invading 6,000 computers in 
four hours” with his November 1988 In¬ 
ternet “worm.” At the time, there was no 
law on the books defining exactly what he 
might have done wrong. Professionally 
and ethically, his actions were wrong, but 
the courts will have to decide whether he 
violated any laws. This places the public 
in an unnecessary and costly situation. 
The issues seem too broad for proposing a 
simple solution, such as outlawing com¬ 
puter viruses. 

Several other recent activities reflect 
the complexity of the issues. Another 
year has passed since the Computer Eth¬ 
ics Subcommittee of COPP submitted its 
seventh draft of the entity position paper 
on computer vandalism for review and 
action by the Computer Society Board of 
Governors. Meanwhile, in the 1989 Gen¬ 
eral Assembly of Pennsylvania, House 
Bill 372 was proposed to amend the 
Crimes and Offenses Act to include “ac¬ 
cessing, altering, damaging, or destroy¬ 
ing any computer, computer system, 
computer network, computer software, 
computer program, or computer data¬ 
base... with the intent to interrupt the nor¬ 
mal functioning of an organization....” 

On another front, the Computer Virus 
Eradication Act of 1989, HR.55, was in¬ 
troduced in the US Congress to amend 
Section 1030 of title 18 of the United 
States Code to provide penalties for “per¬ 
sons interfering with the operations of 
computers through the use of programs 
containing hidden commands that can 
cause harm, and for other purposes.” 

In none of the three situations de¬ 
scribed above was a draft accepted by the 
broader body for which it was created. 

The Committee on Public Policy is 
working with the IEEE/USA Information 
Security Subcommittee on a position pa¬ 
per to guide IEEE members on the ethical 
behavior of computer users and at the 
same time educate legislators and the 
general public about computer crime so 
that lawmakers might take appropriate 
legislative action. 

The subcommittee is trying to cover 
several main principles: 

(1) Any legislation should be compre¬ 
hensive, covering a broad range of com¬ 
puter-related crimes, not just a specific 
set of abuses. 

(2) Legislation should cover the com¬ 
mission of “malicious acts” that cause or 


are intended to cause damage to computer 
and network resources. It should address 
not only unauthorized access but also un¬ 
authorized use within authorized access. 

(3) Legislation should be aimed at 
criminal intent and the effect of that in¬ 
tent rather than focusing on specific hard¬ 
ware or software vulnerabilities and solu- 

(4) Inadvertent conduct should not be 
criminalized; otherwise the law may dis¬ 
courage responsible, creative, and inno¬ 
vative use of computer systems. 

(5) The law should recognize that 
owners and operators of computer sys¬ 
tems have their own responsibilities for 
computer security. Laws, prosecution, 
and penalties cannot guarantee computer 
security. 

Beyond that, the objectives of the leg¬ 
islation must be to 

(1) Provide prosecution in the courts. 

(2) Provide the courts with nationwide 
jurisdiction on computer crime. 

(3) Provide penalties that include pro¬ 
hibiting— for a significant length of 
time — access to non-self-owned com¬ 
puter systems and the transfer of pro¬ 
grams and data. 

(4) Provide for penalties regardless of 
age, although penalties can be graduated 
according to the perpetrator’s ability to 
understand the consequences of the 
crime. 

(5) Avoid day-of-violation terminol¬ 
ogy, since that might unnecessarily com¬ 
plicate the prosecution’s case. 

HR.55 was introduced by Congress¬ 
man Wally Herger, 2nd District, Califor¬ 
nia, 1108 Longworth, House of Repre¬ 
sentatives, Washington, DC 20515, 
phone (202) 225-3076. 

The COPP Subcommittee on Com¬ 
puter Ethics is chaired by Robert (Bob) J. 
Melford, R.J. Melford Associates, 28195 
Manchuca, Mission Viejo, CA 92692, 
phone (714) 830-1443. 

The IEEE/USA Subcommittee on 
Computer Security is chaired by Robert 
S. Powers, MCI Telecommunications, 
8283 Greensboro Dr., Mailstop 1006/ 

625, McLean, VA 22102, phone (703) 
442-5295. 

Please feel free to contact these people 
for more information or to lend your sup¬ 
port to their efforts. 
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Advance Announcement 



The First International Conference on Systems Integration 

April 23-26,1990 Headquarters Plaza Hotel, Morristown, New Jersey, USA 


Sponsored by 

Institute for Integrated Systems Research 
Department of Computer & Information Science 
New Jersey Institute of Technology (NJIT) 

m 

In cooperation with 

IEEE Computer Society 

ACM (Association for Computing Machinery) 

AT&T 

Bell Communications Research (Bellcore) 

Gesellschaft Fuer Mathematik und Datenverarbeitung(GMD) 


IEEE COMPUTER SOCIETY 

£crn 



THE INSTITUTE OF ELECTRICAL 
AND ELECTRONICS ENGINEERS, INC 


This conference focuses on the problems, issues and solutions of integrated system design, implementation and performance. Integration techno¬ 
logies will be emphasized with a focus on computer-aided software engineering, collaborative and distributed systems, and computer integrated 
manufacturing systems. The conference will provide an international and interdisciplinary forum in which researchers and practitioners can share 
novel research, engineering development and strategic management experiences. 


Tutorial-in-Brief 

Monday, April 23, 1990 8:30 am - 5:00 pm 

Tutorial 1: Interconnection Networks for Computer Systems 
Integration 

Chuan-Lin Wu, University of Texas at Austin 
Tutorial 2: Software Engineering with Abstractions 
Valdis Berzins, Naval Postgraduate School 
Tutorial 3A: Optical Data and Knowledge Base Machines 
P. Bruce Berra, Syracuse University 
Tutorial 3B: The Object-Oriented Paradigm and Integrated 
Systems 

Erich J. Neuhold, IPSI-GMD 

Tutorial 4: Systems Engineering Management: Unifying Principles 
for Systems Development Integration 
Tom Gilb, Independent Consultant 
Tutorial 5: The Future of Machine Vision in Manufacturing 
Robert Mitchell, University of Texas at Arlington 


Conference-in-Brief 

Plenary Session Speakers 

• Arno A. Penzias, AT&T Bell Laboratories 
Tuesday, April 24, 1990 9:00 am - 10:30 am 

• Elaine R. Bond, Chase Manhanttan Bank, N.A. 
Wednesday, April 25, 1990 9:00 am - 10:00 am 

• Raymond T. Yeh, Syscorp International, Inc. 
Thursday, April 26, 1990 9:00 am - 10:00 am 

Dinner Banquet Speaker 

Tom Gilb, Independent Consultant 
Wednesday, April 25,1990 7:00pm-9:00pm 


The Conference will be held at the Headquarters Plaza Hotel, 3 
Headquarter Plaza, Morristown, New Jersey, USA. For reservation 
call (201) 898-9100 or (800) 225-1942. Please identify yourself as 
Systems Integration Conference attendant to receive the room rate 
for single occupancy $120/night or double occupancy $140/night. 
Reservations must be received by April 9, 1990. 


Technical program 

There will be three days for the presentation of 85 papers and four 
panels in three tracks. Papers and panels related to the following topics 
will be presented and discussed. 

• System Integration 

• Computer Architecture 

• Artificial Intelligence 

• System Evolutions 

• Communications-Networking 

• Panel: Integrated Design Manufacturing 

• System Environments 

• Communications-Protocols 

• Objects Recognition 

• Panel: Delivering Quality Systems 

• Networking 

• CAD/CAM 

• Formal Specifications 

• Data Management 

• Manufacturing - Factory Floor Applications 

• Standards and Definitions 

• Data Management - Applied 

• Manufacturing - Flexible Manufacturing Systems 

• Panel: System Integration Leading to Distributed Systems 

• Man-Machine Interfaces 

• VLSI - Integration 

• System Application 

• Information Networking 

• Distributed Systems 

• Testing 

• Information Systems 

• Resource Management 

• Design and Networking Issues 

• Panel: Concluding Remarks 


For a full Systems Integration Advance Program, please contact: 
Professor Peter A. Ng 
Institute for Integrated Systems Research 
Dept, of Computer and Information Science 
New Jersey Institute of Technology 
Newark, NJ 07102, USA 
Tel: (201)596-3387 Fax: (201)596-5777 
E-mail: ng_p@vienna.njit.edu 











Important New References Coming Next 


National Institute of Standards & Technology/IEEE 
OSI Implementors Workshop 


OSI (Open Systems Interconnection) is a revolu¬ 
tionary new concept in data communications 
whereby different computers are able to communi¬ 
cate with each other in a global environment. The 
NIST/IEEE OSI Implementors Workshop is a pub¬ 
lic, open, international forum that develops OSI 
Implementation Agreements based upon emerging 
recognized international OSI standards. 

The Workshop accepts as input the specifications 
of these emerging standards and produces imple¬ 
mentation agreements and testing details. Use of 
these agreements is expected to expedite the de¬ 
velopment of OSI protocols and promote interop¬ 
erability of multi-vendor data communications 
equipment. 

The stable set of these agreements give essential 
detail that may be used as the basis of product de¬ 
velopment and conformance testing. The working 
set of agreements give implementors and users a 
timely glimpse of new functionality that may soon 
become stable. Thus, by possession of both the 
Stable and Working documents, the reader will 
have a complete picture of present and future de¬ 
velopments in the world of OSI. 

Each publication contains critical detail necessary 
for OSI knowledge and understanding. The Stable 
and Working documents are aligned, and may be 
used in parallel. Organization is by subject matter, 
and the sections taken together are consistent and 
complementary. 

The key elements of each section of the publication 
are detailed, easy-to-read agreements which are 
vital to a proper understanding of current OSI prod¬ 
ucts and the current status of product development. 
Readers will understand how to define and evaluate 
product requirements; and vendors, contractors, and 
consultants will learn how to interpret user require¬ 
ments in defining product specifications. 

The following professionals will benefit from the 
NIST/IEEE OSI publications: those using data com¬ 
munication products in a multi-vendor environ¬ 
ment (for example, the federal government), prod¬ 
uct developers, systems administrators, hardware 
specialists, software specialists, and communica¬ 
tions specialists. 


M IEEE COMPUTER SOCIETY 


The newest OSI Release! 

Working Implementation Agreements for 
Open Systems Interconnection Protocols, 
Volume 2, Number 1 

Book No. 2042. U.S. Price $56.00. 

This authorized reprint edition contains the full 
text of NISTIR 89-4198, based on the proceedings! 
of the September 1989 NIST OSI Implementor’s 
Workshop. 

Contents: General Information; Sub Networks;] 
Network Layer; Transport Layer; Upper Layers; Ob¬ 
ject Identifiers and Other Registration Issues; Stable 
Message Handling Systems; Message Handling Sys-1 
terns; Stable File Transfer, Access, and Management 
(FTAM) Phase 2; ISO File Transfer, Access and 
Management Phase 3; Directories; Stable Security 
Agreements; Security; ISO Virtual Terminal Proto¬ 
col; Transaction Processing; Office Document Ar¬ 
chitecture; Network Management; Remote Data¬ 
base Access (RDA); Manufacturing Message Speci¬ 
fication (MMS); References. 


Special Standing Order 
Subscription Offer! 

The NIST/CS Press OSI publications are avail¬ 
able as a standing order subscription at a 
25% discount. Order the annual stable imple¬ 
mentation agreements or both the annual sta¬ 
ble implementation agreements and the 
quarterly working agreements. You will auto¬ 
matically receive these publications as soon 
as they are published and will save 25% off 
the list price! 

Annual Stable Implementation Agreements: 
Order No. 1145. 

Annual Stable Implementation Agreements 
and Quarterly Working Agreements: 

Order No. 1147. 


♦ 


IEEE 


THE INSTITUTE OF ELECTRICAL 
AND ELECTRONICS ENGINEERS. INC. 














Month From Computer Society Press 


FUTUREBUS+ 

Draft Standard P896.1: Logical Layer Specifications 


| Book No. 1009. U.S. Price $32.00. 

S f uturebus+ is a revised and substantially extended 
[.version of the original IEEE 896.1-1987 Futurebus 
[standard, where the basic protocols and facilities 
within this specification were developed. The Fu- 
Iturebus represents a major paradigm shift for the 
[computer industry. It is designed a-priori to be a 
standard , lasting multiple generations of computer 
[technology. The name “Futurebus” itself stems from 
[ its goal to bridge the present with the future, 
Ithrough its scalability, the technology-indepen- 
Idence of its protocols, and explicit provision for 
Ihooks to compatibly extend the specification to fu- 
Iture needs. Systems built with the Futurebus will 
benefit end users immensely, by being “gracefully 
upgradable", preserving investments already made 
in the boards, enclosures, power systems and other 
hardware (and software) as new improvements in 
[processor architecture, and clock speed, are imple¬ 
mented. 

Futurebus+ is a standard for a multiple backplane 
bus architecture designed specifically to provide 
[performance scalability over both cost and time for 
multiple generations of single- or multi-bus multi¬ 
processor systems. This architecture is principally 
intended for 64-bit address and data operation, 


however a fully compatible 32-bit subset is pro¬ 
vided, along with compatible extensions for 128- 
and 236-bit data transfers. 

It is intended that this standard, a draft prepared 
by the P896.1 Working Group of the Microproces¬ 
sor Standards Committee, be used as a key compo¬ 
nent of a profile specified in IEEE 896.2 (Future- 
bus+ Physical Layer and Profiles). 


Special Standing Order 
Subscription Offer! 

Draft Standards published by the CS Press 
are available as a standing order subscription 
at a 25% discount. You will automatically re¬ 
ceive all draft standards as soon as they are 
published and will save 25% off the list price! 

Draft Standard Standing Order Subscription: 
Order No. 1152. 


ORDER TODAY! 

G Send me_copies of Working Implementation Agree¬ 

ments for OSI Protocols, Book Number 2042, at $56.00 
each. 

□ Enter my standing order for the Annual Stable Implemen¬ 
tation Agreements, Order Number 1145. 

G Enter my standing order for the Quarterly Working Agree¬ 
ments, Order Number 1147. 

G Send me __ copies of Futurebus+ Draft Standard 

P896.1: Logical Layer Specifications, Order Number 1009, 
at $32.00 each. 

G Enter my standing order for all Draft Standards published 
by the Computer Society Press, Order Number 1152. 

Total price of books ordered: _ 

(standing orders will be billed when each book is published) 

California residents add 6% sales tax: _ 

Handling Charges*: _ 

GRAND TOTAL: _ 


G Check enclosed 
G Charge it: 

Card Name_ 

Card *_ 

Exp. Date_ 

•Handling Charges: Base 
ing sales tax. For orders 
$75.00 add $5.00; $75.01 
$8.00; over $200.00 add 

IN A HURRY? 

Call Toll Free: 1-800-CS-BOOKS 
In California call: (71-t) 821-8380 
Or fax your order: (71-t) 821~t010 

Name_ 

Orgar 
Address_ 


15.00. 


IMPORTANT: 

If you are using a 
purchase order, please 
attach this coupon' 


Mail to: IEEE Computer Society, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720 


























PRODUCT REVIEWS 


Editor: Richard Eckhouse, UMASS-Boston, Harbor Campus, Boston, MA 02125, Compmail+, r.eckhouse; Bitnet, eckhouse@umbsky; CompuServe, 70516,556 

Keeping in touch through Windows 


Noah Davids, Stratus Computer 

As a purchaser of Microsoft Windows/ 
286 version 2.11 was pleased to find the 
standard package includes a terminal 
emulator. However, I quickly discovered 
the emulator is very primitive. It has no 
file transfer capabilities, no script lan¬ 
guage, and limited text capture capabili¬ 
ties. When I called Microsoft’s technical 
support line to ask about these limita¬ 
tions, the representative I spoke with was 
amazed that I was using it. The emulator 
did, however, serve one useful purpose 
— it helped me remain in touch with the 
outside world while I desperately 
searched for a more powerful emulator. 

This review describes five terminal 
emulators that run under MS Windows/ 
286: Procomm Plus v. 1.1B, Dynacomm 
2.0 Asynchronous Edition, Term 6.1.0, 
Crosstalk for Windows 1.0, and APE 
(A Programmable Emulator) 1,08a. (See 
Table 1 for the company names, ad¬ 
dresses, and prices.) All are much more 
powerful than the terminal emulator in¬ 
cluded with Windows/286.1 ran all the 


emulators on a 12-MHz 286 with 1 M- 
byte of memory and an EGA monitor. 

System requirements 

I obtained the disk space requirements 
shown in Table 2 by installing the files 
from the distribution disks onto my sys¬ 
tem and seeing how much disk space 
they used. I obtained the minimum disk 
space by deleting all the files not actu¬ 
ally needed to run the program. This in¬ 
cluded ancillary files, like scripts, and 
help text. 

The amount of memory used by Dyna¬ 
comm, Crosstalk, and APE depends on 
the configured size of the scrollback 
buffer and, in Crosstalk’s case, the con¬ 
figured size of the communications 
buffer. I obtained the memory limits by 
running the programs with the buffers set 
to their minimum and maximum values. 
APE does not have a maximum value. It 
allocates memory for the scrollback 


buffer as needed, up to the limit of avail¬ 
able memory or the configured size of 
the scrollback buffer. The amount of 
memory allocated will vary depending 
on the length of the lines; longer lines 
take more memory. The memory usage I 
measured was for 1,000 lines averaging 
about 65 characters long. I set Pro- 
comm’s memory requirements by adjust¬ 
ing the memory setting in the PIF file 
down from the distribution value to a 
value just above the point where “not 
enough memory” errors were generated 
when the program was loaded. 

All the distribution files came on 5.25- 
inch disks. Dynacomm and APE came on 
1.2-Mbyte disks; the others came on 360- 
Kbyte disks. All the packages can be or¬ 
dered with 3.5-inch disks. 

All the programs but Procomm require 
MS Windows/286 or 386. Procomm re¬ 
quires only DOS 2.0 or greater. How¬ 
ever, you can run this well-behaved DOS 
program in a window. It even comes 
with Windows’ PIF file. 


Table 1. The products. 


Product 

Company 

Addresss 

Price 

RS Number 

Procomm Plus 

version 1.1B 

DataStorm 

Technologies 

PO Box 1471 

Columbia, MO 65205 

$89 

Reader Service 21 

Dynacomm 2.0 

Asynchronous Edition 

Future Soft 

Engineering 

1001 S. Dairy Ashford, 

Suite 203 

Houston, TX 77077 

$295 

Reader Service 22 

Term 6.1.0 
(dated 9/12/89) 

Century Software 

5284 S. 320 Suite C-134 

Salt Lake City, UT 84107 

$195 

Reader Service 23 

Crosstalk for Windows 1.0 

Digital Communications 
Associates 

1000 Holcomb Woods 
Parkway, Suite 440 

Roswell, GA 30076 

$195 

Reader Service 24 

APE 1.08a 

(A Programmable Emulator) 

HI-Q International 

1142 Pelican Bay Dr. 
Daytona Beach, FL 32119 

$189 

Reader Service 25 
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Table 2. Disk and memory requirements (in Kbytes). 



Disk Space 
min/max 

Memory 

min/max 

Procomm 

362/660 

227/286 

Dynacomm 

400/1,000 

80/103 

Term 

185/751 

223 

Crosstalk 

346/652 

75/136 

APE 

404/490 

103/173 (for 1,000 lines) 


License agreement 

The Procomm license agreement is a 
sight for sore eyes. It licenses an individ¬ 
ual, not a system or CPU. That meant I 
could install it on both my home and 
work systems. The Dynacomm, Term, 
Crosstalk, and APE programs all license 
a system, so you cannot legally install 
them on more than one system at a time. 


Documentation 

Ease of use. Except for Term, the 
manuals have an organization that makes 
them easy to use, meaning easy to find 
things in. However, all the manuals but 
Crosstalk separate the script functions 
from the script commands. Each group is 
organized alphabetically, but about half 
the time I looked in the wrong section 
first. 

APE takes this segregationist approach 
a step further and puts the file I/O and 
file transfer commands in separate sec¬ 
tions as well. 

The organization of Term’s manual is 
confusing. The manual is written for the 
MS-DOS version of Term 6.0. Two sets 
of release notes, one for version 6.1 and 
one for the Windows user interface, de¬ 
scribe changes made to the 6.1 Windows 
version. Whenever I looked for some¬ 
thing, I had to check both the manual and 
the 6.1 notes. The 6.1 notes only have a 
table of contents, no index, which made 
looking through them even harder. More¬ 
over, not only do the script functions and 
commands appear in separate sections, 
but the script commands are not listed 
alphabetically. Related commands are 
listed together; for example, the Wait 
command is listed under Dwait. 

The Procomm and Crosstalk manuals 
are bound like paperback books. That 
means that once I found what I was look¬ 
ing for, I usually had to put something on 
the manuals to keep the page from flip¬ 
ping. I finally ended up breaking the 
spines. The Dynacomm, Term, and APE 
manuals all come in three-ring binders. 

Completeness. Crosstalk has the only 
documentation I consider complete. It 
fully describes the Crosstalk system, in¬ 
cluding error messages. 

Dynacomm, Term, and APE have 
fairly complete documentation. I found a 
minor error in both the Term and APE 
manuals (see “Terminal emulation” be¬ 
low), and all three omit a section ex¬ 
plaining error messages. APE’s manual 
provides a list of error messages, but a 
list without explanation is useless. 
Procomm’s manual includes a section on 
error messages, but had a more glaring 


problem: The section describing the 
script language (pages 181 through 212) 
was missing. 


Installation procedures 

Procomm. Procomm comes on two 
disks, a program disk and a supplemental 
disk. The manual explained that I could 
install Procomm in either of two ways. I 
could simply copy all the files off the 
distribution disks into a directory of my 
choice, then run the pcsetup.exe pro¬ 
gram. Or, I could run the pcinstal.exe 
program. Pcinstal would copy the files 
into any directory I indicated, then run 
Pcsetup. When I ran Pcinstal, I found 
that only the files from the program disk¬ 
ette were copied, so I had to copy the 
supplemental diskette manually anyway. 
Other than that, installation of Procomm 
was simple and quick. 

Dynacomm. Dynacomm does not 
have an installation utility. The manual 
said to copy the files from the distribu¬ 
tion disk into whatever directory I 
wanted. Just for the record, I had no 
trouble copying the files. 

Term. Term comes with an installa¬ 
tion batch file that let me change the 
drive letter but not the rest of the direc¬ 
tory path. The batch file just copies the 
files from the three distribution diskettes, 
so I did it manually. After copying the 
files, the batch file runs a program called 
brand.exe. When I ran the program, it 
prompted me for Term’s serial number 
and activation key. The serial number is 
on the diskettes, and the activation key 
comes on a sheet of paper folded into 
one of the distribution disk envelopes. 
This is not a copy protection scheme, be¬ 
cause after “branding” I was able to 
move Term to a different directory. 


However, Term would not run prior to 
“branding.” Installation was not difficult, 
but it required me to read the batch file 
to figure out how to install Term where I 
wanted it. 

Crosstalk. Crosstalk for Windows is 
installed by an install.exe program. This 
program does significantly more than 
just copy the files from the two distribu¬ 
tion disks. By default it will create the 
xtalk directory under c:\windows. How¬ 
ever, you can change that. Under the 
xtalk directory it creates three subdirec¬ 
tories: one for download and capture 
files (initially empty), one for phone 
book entries (which also starts out 
empty), and one for script files (which 
has many example scripts). 

The program also lets you modify your 
win.ini file during the installation proce¬ 
dure. The win.ini file has an xtalk entry 
that includes things like the communica¬ 
tion and scrollback buffer sizes, and the 
paths to the file, phone book, and script 
directories. I had no problems installing 
Crosstalk. 

APE. APE’s installation batch file cre¬ 
ates an APE directory off of C: and cop¬ 
ies the files from the distribution disk 
into that directory and the scripts direc¬ 
tory it creates under APE. It also creates 
a log directory under APE, used as the 
default target for downloads. Since the 
batch file did not give me a chance to 
change the target directory, I modified it 
before I ran it. 

One of the files copied contains the 
win.ini directives for APE. The last thing 
the batch file did was tell me to merge 
that file into my win.ini file. APE’s 
win.ini directives contain the same sort 
of information as Crosstalk’s. I had to 
change the directives that contained 
paths of c:\ape before I could update my 
win.ini file. Installation was not difficult, 
but far from automatic. 
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Table 3. Terminals supported. 



Procomm 

Dynacomm 

Term 

Crosstalk 

APE 

ADDS Viewpoint 

Yes 

60 




ADM 

3/5 


1 



ANSI 

X3.64 


Yes 

Yes 

X3.64 

Bull HN 





PCT/VIP7800 

Heath/Zenith 19 

Yes 





IBM 

3101/3270 

3101 

3101 

3101 


Televideo 900 

Yes 

925/950 

912/925 



TTY 

Yes 


Yes 


Yes 

VT 

52/100 

52/100/220 

52/100/220 

52/102 

52/100/220 

Wyse 

50/100 


50 



Vidtex 


Yes 


Yes 


Custom 





Yes 


Nit picks. Before leaving the subject 
of installation, I have a nit to pick with 
Term, Crosstalk, and APE. These are all 
MS Windows programs, but you must 
run their installation procedures from 
DOS. I got these packages so I would not 
have to run native DOS! 


Customization 

Crosstalk provides menu bar options 
and dialog boxes for customizing all as¬ 
pects of the system. Dynacomm uses 
menu bar options and dialog boxes for 
customizing everything except keyboard 
remapping. To remap the keyboard, I had 
to use script commands. I had no trouble 
customizing either system. 

Procomm has its own forms interface, 
which is also easy to use. 

I found Term and APE much harder to 
customize. Some of Term’s features, like 
the communication line parameters, I 
could change via a menu bar option, but 
many features required me to use the 
command language. You can change 
most of APE’s features via the menu bar 
options and dialog boxes. However, 
some features you can change only by 
script commands, while others require 
you to directly change the win.ini file. 

There are three areas of customization. 
Host interaction includes communication 
line parameters, terminal emulation, mo¬ 
dem support, and file transfer capabili¬ 
ties. The user interface includes custom¬ 
izing the window, displaying text, and 
constructing macros. The third area in¬ 
cludes features unique to a package or 
that occur in just a few of the packages. 

Communication line parameters. All 

the packages are very flexible when it 
comes to customizing the communication 


line parameters. I do not think anyone 
will have problems configuring any of 
the packages to support any type of host 
connection. All of them support the stan¬ 
dard set of flow-control options, parities, 
stop bits, and data bits. All of them sup¬ 
port baud rates up to 19,200. Term ex¬ 
tends baud rate support to 38,400, while 
Procomm extends it to 115,200. They all 
work with COM 1 and COM 2. Term and 
Procomm extend support to COM 6 and 
COM 8, respectively. Dynacomm sup¬ 
ports COMBIOS and NetBIOS as well as 
COM 1 and COM 2. Procomm takes 
flexibility a step further by allowing you 
to configure the port address and inter¬ 
rupt level of the COM ports. 

Terminal emulation. Table 3 lists the 
terminal types supported. I have included 
the actual terminal model numbers when¬ 
ever the documentation listed them. In 
those cases where I could not determine 
a model number, I have just listed a 
“yes.” 

APE has a script function that custom¬ 
izes the actions taken when a control se¬ 
quence is received. Along with keyboard 
remapping this, in principle, allows APE 
to emulate any type of terminal. In prac¬ 
tice it’s not that powerful, since you can 
only emulate ANSI X3.64 terminal fea¬ 
tures. Still, I created a useful emulation 
of a Stratus VT102 terminal. 

All the packages also provide the abil¬ 
ity to customize the keyboard by chang¬ 
ing the characters sent to the host when 
certain keys are pressed. Table 4 shows 
the keys that each package can customize 
and the maximum number of characters 
that can be sent. The cursor control keys 
are the arrow, page, home, and end keys 
on the numeric keypad or the extended 
keys on the keyboard. The numeric key¬ 
pad keys are the keys on the numeric 


keypad when NumLock is set. Note that 
pressing shift when NumLock is set has 
the effect of turning NumLock off for 
that keypress, so the shift numeric key 
pad is the same as the cursor control 
keys. The Dynacomm and APE manuals 
do not state a limit on the number of 
keys; I just stopped after 100. 

In general, keyboard customization 
gave me no trouble. However, in Term I 
could not customize the alternate func¬ 
tion keys. According to technical sup¬ 
port, alternate function keys cannot be 
customized in the Windows version of 
Term, but the Windows release notes do 
not explain this. I also had a minor prob¬ 
lem with APE, failing to customize the 
control-down and control-end keys. APE 
uses these keys as accelerator keys for 
script handling. I was told that this con¬ 
flict would be resolved in a future re¬ 
lease. APE also has an interesting fea¬ 
ture, letting you customize the “5” key of 
the numeric keypad, which normally 
doesn’t do anything unless you’re in 
NumLock mode. 

Modem support. Built-in modem sup¬ 
port varies from Procomm, which sup¬ 
ports only the Hayes modem, to 
Crosstalk, which lists 34 modems in its 
selection box. In Procomm, Dynacomm, 
and Crosstalk, you customize the modem 
by supplying the command strings nor¬ 
mally typed from the keyboard and the 
response strings the modem normally 
sends back to the terminal window. 

These packages take the command 
strings, send them to the modem, and 
compare the modem’s response with the 
response strings. 

Term and APE use a modem control 
script. These scripts send the command 
strings to the modem and interpret the 
modem’s responses. This mechanism 
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Table 4. Keyboard customization. 



Procomm 

Dynacomm 

Term 

Crosstalk 

APE 

Unshifted Function Keys 

10 

100+ 

66 


100+ 

Shifted Function Keys 

10 

100+ 

66 

40 

100+ 

Control Function Keys 

10 

100+ 

66 

40 

100+ 

Alternate Function Keys 


100+ 

66 



Control Shift Function Keys 





100+ 

Cursor Control Keys 

10 

100+ 

66 


100+ 

Shifted Cursor Control Keys 


100+ 



100+ 

Control Cursor Control Keys 


100+ 



100+ 

Alternate Cursor Control Keys 


100+ 




Numeric Keypad Keys 

10 

100+ 

66 



Control Numeric Keypad Keys 


100+ 




Alternate Numeric Keypad Keys 


100+ 




Alphabetic Keys 


100+ 




Shifted Alphabetic Keys 


100+ 


40 

100+ 

Control Alphabetic Keys 


100+ 


Alternate Alphabetic Keys 


100+ 

66 



Other QWERTY Keys 


100+ 




Shifted Other QWERTY Keys 


100+ 




Control Other QWERTY Keys 


100+ 




Alternate Other QWERTY Keys 


100+ 





provides the most flexibility, but is also 
the most complex. 

File transfer. The Xmodem and Ker- 
mit file transfer protocols are supported 
by all the packages. Most of the pack¬ 
ages also support Ymodem, Zmodem, 
and Compuserve-B, as well as lesser 
known and proprietary protocols. Pro- 
comm supports the most protocols with 
13 and provides a way to add support for 
new protocols through its external proto¬ 
col definition. 

All the packages also provide a way to 
upload text files just by sending the char¬ 
acters to the host. The protocol parame¬ 
ters for these uploads consist of customi¬ 
zable delays after each character is sent 
and after each line is sent. 

All the packages can also wait for the 
host to send a special character at the end 
of each line. Dynacomm, Crosstalk, and 
APE can wait for each character sent to 
the host to be echoed as well. 

Customizing the window. Dyna¬ 
comm, Crosstalk, and APE divide the 
window into several sections. They also 
allow extensive control over which sec¬ 
tions are displayed. I found the default 
Crosstalk and APE windows very busy. I 
simplified them by removing some sec¬ 


tions. Crosstalk allows you to set the 
configuration and forget about it. A bug 
in APE makes it necessary to remove the 
unwanted sections via commands in the 
startup script. Dynacomm has its own 
built-in editor, useful for creating scripts. 
When creating a script, I would split the 
window in two with one side showing 
the terminal window and the other show¬ 
ing the editing window. This made script 
editing and testing very easy. 

Colors. All the packages but Procomm 
allow some control over the colors used 
to display text with normal, bold, under¬ 
line, reverse, or blinking attributes. Pro¬ 
comm, because it’s a standard DOS ap¬ 
plication running in a Window, thinks 
it’s running on a system with a mono¬ 
chrome screen. It correctly displays 
underlined and reverse text, but blinking 
and bold text can only be displayed in 
normal or reverse characters. 

Term and Dynacomm let you map 
each of the five attributes to a separate 
color. Crosstalk and APE let you map 
normal, bold, and blinking attributes to a 
color. However, only Dynacomm cor¬ 
rectly handled cases that called for dis¬ 
playing the text in two different colors, 
such as bold, blinking text. It gets around 
this conflict because its attribute specifi¬ 


cation dialog box lets you select a color 
for each possible combination of attrib¬ 
utes. Dynacomm not only let me specify 
a color, but also let me specify a charac¬ 
ter type. Each of the text attributes can 
be displayed by a combination of normal, 
bold, underline, italic, or reverse charac¬ 
ters in any color. Crosstalk and APE 
correctly add the underline and reverse 
attributes to the color used to display the 
normal, bold, and blinking attributes. 

Fonts. Dynacomm, Crosstalk, and 
APE also let me select the font I wanted 
to use. Dynacomm can use any font in¬ 
stalled on the system, while Crosstalk 
and APE are limited to the System, Ter¬ 
minal, and Courier fonts. Crosstalk also 
has its own VT102 font. 

You can also select different character 
sizes. Crosstalk’s VT102 7x7 font is the 
smallest. It can display 24 rows in a win¬ 
dow slightly more than half of the screen 
height and display 80 columns with 
enough room left between the right edge 
of the window and the edge of the screen 
to comfortably display icons. 

Dynacomm’s and APE’s smallest font 
is the 10-point Courier (10x5 pixels). It 
displays all 24 rows in a window roughly 
three-fourths of the screen height and 
all 80 columns in roughly two-thirds of 
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Procomm 

Dynacomm 

Term Crosstalk 

APE 

Number of Macros 10 

32 

64 

25 

Characters in Macro 50 

62 

40 

100+ 


Table 5. Keyboard macros. 


the screen width. Crosstalk can also use 
this font. 

The Courier 15x15 font is the largest 
font usable by Crosstalk and APE. In a 
maximized window it can display 20 
rows by 42 columns. Dynacomm’s larg¬ 
est font is Times Roman 63-point. It can 
display three rows by 13 columns in a 
maximized window. 

Procomm and Term use the Terminal 
8x8 font. With this font, 24 rows are dis¬ 
played in about three-fourths of the 
screen height; by stretching the window 
across the screen, 79 columns can be dis¬ 
played. This is the font I used with all 
the packages. 

Keyboard macros. All the packages 
but Term offered some form of keyboard 
macro. The difference between keyboard 
remapping and macros is that in remap¬ 
ping the characters are sent to the host 
while a macro can execute any script 
command. (See Table 5 for the number 
of macros offered by each program.) 

Procomm’s macros are invoked by 
pressing Alt-A, where N ranges from 0 to 
9. Pressing Alt-M displays the macro 
editing form, used to create, edit, and de¬ 
lete macros. The form presentation and 
removal was fast enough that I could 
also use it as a pop-up reminder of which 
N went with which macro. 

Procomm’s macros are stored in a 
macro file. Multiple macro files can store 
10 macros each. The macro editing form 
is also used to save and reload these 
macro files. 

Dynacomm, Crosstalk, and APE have 
a separate screen section that displays 
buttons associated with the macros. 
Clicking on the button will execute the 
macro. If the button section is not shown, 
Dynacomm reverts to a non-mnemonic 
key press (Alt-Ctrl-function key N). The 
process of redisplaying the button sec¬ 
tion or of displaying the button editing 
dialog box takes considerable time. 

Crosstalk’s button labels can also be 
displayed under the “user” menu bar op¬ 
tion. Selecting that option displays a 
menu of the button labels. Selecting a la¬ 
bel executes the macro. I found this op¬ 
tion very useful. 

APE can display a maximum of 25 
buttons. You can adjust the size of the 
buttons to fit the labels or to save space. 


The number of rows of buttons will ex¬ 
pand so that all buttons associated with a 
macro are displayed. You can also re¬ 
move the button section. In that case you 
invoke the macros via a control key. By 
default the control key corresponds to 
the first character of the button label. 
However, you can change that by flag¬ 
ging the key character when you define 
the button. 

Memory requirements. As noted in 
the system requirements section, Dyna¬ 
comm, Crosstalk, and APE give you 
some control over their memory require¬ 
ments by allowing you to configure cer¬ 
tain buffer sizes. 

You can make Dynacomm’s scroll- 
back buffer large enough to hold 399 
lines. Or, you can choose not to allocate 
it at all. 

Crosstalk has two buffers: a communi¬ 
cations buffer (from 2 Kbytes to 16 
Kbytes) and a scrollback buffer (from 0 
Kbytes to 64 Kbytes). 

APE does not have a maximum size 
for its scrollback buffer. The buffer is al¬ 
located in 4-Kbyte chunks on an as- 
needed basis and will grow until no more 
memory is available or until the size re¬ 
quested is reached. As you can see in 
Table 2, changing these buffer sizes can 
significantly change the amount of mem¬ 
ory required. Since programs using a 
COM port cannot be swapped out of 
memory by Windows/286, memory re¬ 
quirements are still a significant issue. 

Unique features. APE has several 
unique features I think worth mention¬ 
ing. I already mentioned the ability to 
build a custom terminal emulation. APE 
also allows column-by-column cutting to 
the clipboard. This means I can cut any 
arbitrary box of text; moving to the next 
line does not select the rest of the previ¬ 
ous line. 

Both Dynacomm and APE have a 
monitor mode. In this mode Dynacomm 
displays all text as a hex dump with the 
hex values of the characters on the left 
portion of the terminal window and the 
actual characters on the right portion. 

APE has both a hex mode and a mne¬ 
monic mode. In the mnemonic mode the 
printing characters are displayed nor¬ 
mally and control characters are dis¬ 


played in their ASCII abbreviations; for 
example, a control L is displayed as 
<FF> (form feed). I found this a great 
help when building a script that did not 
continue as expected. It turned out that 
my host was embedding a control se¬ 
quence in the middle of the text I was 
waiting for. 


General usage 

I evaluated each package using COM 
1 at 19,200 baud and its VT100 (VT102 
for Crosstalk) terminal emulation. 

Startup. Only Term starts up in a win¬ 
dow that displays a full terminal screen 
(25 lines by 79 columns). Procomm and 
Dynacomm start out with a smaller win¬ 
dow that must be manually sized to dis¬ 
play a full terminal screen. 

Crosstalk and APE also start out with 
a smaller window, but both can be sized 
by script commands. They also provide 
script commands that let me move the 
window. It sounds like a small thing, but 
having to manually adjust the size and 
position of the window every time I 
started the other packages got to be a 
real drag. 

All the packages have start-up scripts, 
but some are more useful than others. I 
found I did not need to execute a start-up 
script with Procomm or Dynacomm. 
Their configuration files recorded every¬ 
thing but the window size and position 
(the one thing the script could not set). 
Term has two start-up scripts, one exe¬ 
cuted when the system is first invoked 
and one executed after the COM port is 
initialized. I used Term’s script to set the 
system’s colors. I used Crosstalk’s and 
APE’s start-up scripts to size and posi 
tiori their windows. 

Crosstalk and APE allow you to 
change the name of the start-up script. 
Crosstalk makes good use of this by hav¬ 
ing the installation procedure set the 
start-up script to an introduction script. 
The first time I ran Crosstalk, I got a use¬ 
ful introduction to the system. One of the 
functions of the introduction script is to 
clear the name of the start-up script so it 
only runs once. 

User interface. Dynacomm, 

Crosstalk, and APE make full use of the 
Windows menu bar and dialog boxes. 
They all provide keyboard shortcuts for 
many menu functions. Crosstalk also 
provides some interesting mouse short¬ 
cuts. Clicking on various parts of the 
status and information line will let you 
change the line configuration or enter 
scrollback mode. I found each of the sys¬ 
tems very easy to use. 

Procomm uses a Lotus 1-2-3-style 
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menu or a command-key sequence (Alt 
key plus alphabetic or function key) to 
invoke operations. The command key 
Alt-Fl displays a full screen of help that 
lists all the other command keys. The hot 
key that displays the Lotus-style menu 
can be changed as part of the customiza¬ 
tion procedure. Most operations display a 
full screen form once invoked. The 
menus and forms are displayed quickly. I 
had no trouble using the system. 

The Term interface looks like the com¬ 
pany stopped halfway through the con¬ 
version from a non-Windows to a Win¬ 
dows interface. The menu bar offers only 
a few options, and almost everything is 
done via commands. 

In a world of mice, menus, and dialog 
boxes, having to type commands could 
be considered an unfriendly interface. 
Term, however, takes the concept of an 
unfriendly command language to the ex¬ 
treme. For example, I tried to set the 
COM port to 19,200 baud, odd parity, 7 
data bits, and 1 stop bit with the follow¬ 
ing command: 

baud 19200, odd, 7, 1 
The following error was generated: 

NONE, EVEN, ODD, MARK or 

SPACE expected 

So I tried 

baud 19200, ODD, 7, 1 

and got the same error message. The cor¬ 
rect command is 

baud 19200,odd,7,l 

Term also has two types of commands. 
The first type requires a single character; 
the second requires the full command 
name. However, to enter the second 
type of command, you must begin with 
the colon character. Otherwise, you end 
up executing a different command or 
get an error. I almost always forgot the 
colon and ended up executing the wrong 
command. 

Another problem is that the left arrow 
acts like the backspace key when enter¬ 
ing a command in Term. I could not cor¬ 
rect a mistake by repositioning the cursor 
and deleting or inserting in the middle of 
the command line. I had to retype the en¬ 
tire command from the last mistake. 

I got used to the Term interface. After 
a while it no longer caused me trouble, 
but the learning curve was certainly the 
steepest of the five systems. 

Cursor shape. The cursor is not im¬ 
portant until you can’t find it. Two of the 
packages gave me some trouble with the 


All my attempts to 
connect to a host using 
the dialing directory 
failed. I finally bypassed 
the dialing directory and 
used a script to control 
the interaction with the 
modem and log in to my 
host. I had no trouble 
doing that. 


cursor. Term’s cursor is a nonblinking 
underline. I had a lot of trouble finding it 
when it was randomly positioned in a 
screen full of text; for instance, after a 
text search in my host’s full-screen text 
editor. I had to move the cursor up and 
down several lines to find it. 

Dynacomm gave me a choice of cursor 
spaces: an underline or block, and blink¬ 
ing or not. The default is a blinking 
block. When the cursor was moving rap¬ 
idly, it tended to disappear, causing me 
to overshoot the character I wanted to 
stop on. Changing to a nonblinking block 
kept the cursor visible. It was also large 
enough that I could easily find it any¬ 
where on the screen, even though it 
didn’t blink. 

Procomm’s and APE’s default cursor 
shape is a blinking underscore. I had no 
trouble finding either, and neither tended 
to disappear when moving rapidly. 

Crosstalk’s default cursor shape is a 
blinking box. It also was easy to find and 
remained visible when moving rapidly. 

Crosstalk and APE let me change the 
cursor shape to an underline, vertical bar, 
or block, and have it blink or not blink. 

On-line help. All the packages but 
APE have some kind of on-line help. 
Procomm’s help is context sensitive and 
available by pressing Alt-Z. I found it 
very useful. However, no on-line help 
covers the script commands. 

Dynacomm, Term, and Crosstalk pro¬ 
vide help via a menu bar option. Select¬ 
ing Help puts you in a help dialog box 
or, in Term’s case, a help form. 

Dynacomm presents a list of topics to 
scroll through and select. The list in¬ 
cludes the syntax of all the script func¬ 
tions and commands. I could even select 
a command or function and have its syn¬ 
tax pasted into my script file. I liked that 
feature, but in general I found the help 


presentation confusing. About half the 
time I went looking for something, I 
didn’t find it. 

Crosstalk’s help system also gives a 
scrollable list of topics. Selecting a topic 
calls up quick, simple explanations and 
refers you to the manual for details. 
Requesting help on any of the script 
commands also yields a referral to the 
manual. 

Term’s help includes all its commands 
and functions, but none of the menu bar 
options and no general topics. To get 
help about file transfers, I had to recog¬ 
nize the file transfer commands. Since a 
script is a sequence of commands, the 
script language was well documented. 

Dialing the host. Typically, you con¬ 
nect to a host with Procomm by selecting 
the host’s name from the dialing direc¬ 
tory. The dialing directory contains the 
host name, phone number, line parame¬ 
ters, and a start-up script. A dialing di¬ 
rectory file can have information on 200 
hosts, and you get multiple dialing direc¬ 
tory files. All my attempts to connect to 
a host using the dialing directory failed. I 
believe my modem caused the problem. 

It seems to be sensitive to typing speed. 

If characters are sent too fast, it does not 
see them. However, when dialing a num¬ 
ber via the dialing directory, Procomm 
does not show the interaction with the 
modem, so I could not see how the mo¬ 
dem actually responded. This made de¬ 
bugging very difficult. I finally bypassed 
the dialing directory and used a script to 
control the interaction with the modem 
and log in to my host. I had no trouble 
doing that. 

Dynacomm does not have a dialing di¬ 
rectory. Instead it has a dialog box for 
entering the number to dial. As with Pro¬ 
comm, I could not get any numbers di¬ 
aled. However, the reason was different. 
My modem requires a Ctrl-E to get its at¬ 
tention. However, Dynacomm does not 
accept control characters when you enter 
the modem control strings. It doesn’t re¬ 
port any errors, but it never sends the 
control characters to the modem. As with 
Procomm, Dynacomm gives you no way 
to watch the interaction between it and 
the modem during the dialing, so I had a 
heck of time figuring out what was going 
wrong. I finally called tech support and 
was told about the control character re¬ 
striction. I ended up putting all the dial¬ 
ing controls into scripts. 

I could not get Crosstalk’s automatic 
dialing to work correctly, either. I always 
got an error indicating that the modem 
gave an unexpected response. Like the 
others, I could not see the modem inter¬ 
action to determine what the response 
was. I gave up and put the modem inter¬ 
action in my log-in script. 
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Procomm has a 
receive buffer, not a 
scrollback buffer. 

It saves the last 9,000 
characters received. 


Term and APE execute scripts to con¬ 
trol the modem and dialing. I did not 
write special scripts. I just embedded the 
modem commands in the log-in scripts 
for each of my hosts. 

Scrollback buffer. All the packages 
except Term have some kind of scroll- 
back buffer. A scrollback buffer saves 
the text that has scrolled off the top of 
the terminal window and lets you scroll 
back through it. I found this feature ex¬ 
tremely useful and a great time saver. 

All the packages allow you to select a 
portion or the entire contents of the 
scrollback buffer and send it to the 
printer or a file. 

One problem with a scrollback buffer 
is that text that does not scroll off the 
terminal window is not saved. This hap¬ 
pens when the host sends cursor position 
commands to rewrite part of the screen. 

Dynacomm’s scrollback buffer is lim¬ 
ited to 399 lines. You can browse using 
the scroll bar, but you cannot search the 
buffer. A drop-down menu option lets 
you copy the terminal window to the 
scrollback buffer. This let me save the 
terminal window when I knew that the 
host command I was about to execute 
would clear the screen (and when I re¬ 
membered). 

To browse though Crosstalk’s scroll- 
back buffer, you must put Crosstalk in 
scroll mode. Pressing the scroll-lock key 
(or selecting Scroll from the edit menu 
or double clicking on the connection 
time on the information line) will toggle 
scroll mode. You can browse using the 
scroll bar or the cursor keys. The large 
buffer size is great, but I wish you could 
search the buffer. When a clear-screen 
command is received from the host, all 
the lines currently displayed in the ter¬ 
minal window are copied to the scroll- 
back buffer. 

You can scroll back in APE using the 
scroll bar (if displayed) or the cursor 
control keys (in keypad mode). Like in 
Crosstalk, lines are added to the scroll- 
back buffer when the host sends a clear- 
screen command. Although APE has no 
built-in search of the scrollback buffer, I 
was able to write a script that did search 


it. Unfortunately, the script wasn’t much 
help. It worked, but so slowly that it 
wasn’t worth executing. It was much 
faster to search manually by scrolling 
backwards and looking. To be fair, I re¬ 
ally didn’t need searching in APE — the 
redisplay was very fast. A search func¬ 
tion would be nice, but manual searching 
of 1,000 lines is feasible. Crosstalk needs 
some kind of searching because the re¬ 
display of each page is so slow it verges 
on painful. 

Procomm has a receive buffer, not a 
scrollback buffer. It saves the last 9,000 
characters received. You can browse us¬ 
ing the cursor control keys. All charac¬ 
ters except control characters are placed 
in this buffer as they are received. This 
made the buffer very hard to read when¬ 
ever my host used cursor positioning 
control sequences instead of carriage re¬ 
turns and line feeds. However, it does 
avoid the problem of losing characters 
not scrolled off the terminal window, 
which the scrollback buffers have. Pro¬ 
comm does have built-in searching of its 
receive buffer. 

Cut and paste. All the packages al¬ 
lowed me to cut text from the terminal 
window or their scrollback (receive) 
buffers and place it in the Windows clip¬ 
board. Term copies the entire terminal 
window to the clipboard — I could not 
cut just a few lines or a portion of a line. 
By default APE automatically adds a car¬ 
riage return after the last character it 
cuts, which I found annoying. Crosstalk 
had to be in scrollback mode before I 
could cut anything, even if what I wanted 
to cut was visible on the terminal win¬ 
dow. 

I encountered a minor problem while 
pasting in Dynacomm. After sending the 
text, it would send a string of null char¬ 
acters. Every null caused my host to 
beep. After a while I dreaded pasting 
anything. 

I had a more serious problem pasting 
in Procomm and Term. The text was sent 
so fast that sometimes my host could not 
keep up. As long as the text was only one 
or two lines, it worked just fine. The 
other packages all applied the pacing 
protocol defined for text uploads, so my 
host had no problems keeping up. 

Executing standard DOS appli¬ 
cations. Windows 286 will not swap any 
program that has acquired one of the 
COM ports. Therefore, to execute a full¬ 
screen DOS application, you must tell 
the program to release the COM port. 
This will cause any incoming characters 
to be lost, but it’s the way things work. 

Dynacomm and APE support easy, fast 
procedures. Dynacomm’s communica¬ 
tion dialog box has a “none” selection 


for COM port. APE has a release option 
on its interface drop-down menu. Since 
APE does not use a dialog box, it’s a 
little faster. 

Crosstalk also has a disconnect option 
on its action drop-down menu, but then it 
puts up a dialog box asking if you’re 

Term required me to initialize a non¬ 
existent COM port. 

The only way to get Procomm to 
disconnect from a COM port is to exit 
Procomm. 

Reconnecting was also fast and simple 
in Dynacomm and APE. Selecting the 
original COM port in Dynacomm’s com¬ 
munication dialog box restored all the 
line configuration settings. Just typing in 
APE would cause it to reacquire the 
COM port. Selecting Connect on 
Crosstalk’s action drop-down menu 
called up a dialog box asking if I was 
sure, then ran the start-up script config¬ 
ured for the host I was connected to. 

Term required me to initialize the 
original COM port, then redefine the line 
configuration. None of this had any ef¬ 
fect on my modem, which maintained 
my connection with my host without 
problems. 


Except for APE, I had 
no trouble doing 
Kermit and Xmodem 
file transfers with any 
of the packages. 


File transfers. Except for APE, I had 
no trouble doing Kermit and Xmodem 
file transfers with any of the packages. 
All the packages provide a display of the 
current status of the transfer. 

All the packages but APE provide a 
large display in the middle of the termi¬ 
nal window. APE provides the informa¬ 
tion on the information line, which I 
found out by accident. Because the usual 
information line was not very useful to 
me, I had removed it. Thus, my first set 
of transfers was done without feedback. 

I had no trouble doing text uploads 
with any of the packages. All the pack¬ 
ages do text downloads via a capture 
mechanism where all incoming text is 
captured to a file. 

Crosstalk makes interesting use of the 
icon when it’s minimized. During an 
upload it shows the percentage com¬ 
pleted; during a download it shows the 
number of packets received. 
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Table 6. Types of waits. 



Procomm 

Dynacomm 

Term 

Crosstalk 

APE 

Wait until a given tin 

re Yes 

Yes 

Yes 

Yes 

Yes 

Wait for a given time 

Yes 

Yes 

Yes 

Yes 

Yes 

Wait for string 

Yes 

Yes 

Yes 

Yes 

Yes 

Wait for idle time 


Yes 

Yes 

Yes 

Yes 

Wait for specified 


Yes 


Yes 


no. of characters 







Editing. Procomm has an editor called 
Pcedit. This editor is a separate EXE file 
and comes with its own PIF file. It has a 
fair number of cursor control functions, 
allows searching, and has some macros 
for inserting some of the common script 
language functions. However, when I 
tried to run it from within Procomm, I 
got the message that there was not 
enough memory. 

Dynacomm has a built-in editor for 
things like memos and scripts. This edi¬ 
tor uses the Dynacomm window, which 
can be split to show an editor session in 
one subwindow and the terminal session 
in another. It let me create and compile a 
script in one subwindow, switch to the 
terminal subwindow to run it, then 
switch back to the editor subwindow to 
make corrections. If a syntax error is de¬ 
tected, the cursor is positioned on the 
line containing the error in the editor 
subwindow. I found this very handy. 

Term’s default editor is Edlin. I tried 
to execute it and got a “not enough mem¬ 
ory” alert box and a hung system. The 
setup procedure let me change the editor 
to notepad.exe. However, when I in¬ 
voked it I got the same alert box and 
hung system. 

Crosstalk’s default editor is Notepad. 
You can change that, but I saw no reason 
to. If during script compilation or execu¬ 
tion you get an error, it will ask if the 
script file should be edited. If you an¬ 
swer yes, it will bring up a notepad win¬ 
dow with the script file in it. However, 
the cursor is always positioned at the 
start of the file. I found it easier to just 
keep an open notepad window containing 
my script. 

APE doesn’t have any kind of built-in 
editor and doesn’t try to invoke one if it 
finds an error in a script. 

Multitasking. I tested the impact of 
each package on Windows’ nonpreemp- 
tive multitasking ability by running a 
program that continuously updated a 
window and seeing how much it slowed 
down when I ran each of the packages. 
My report is qualitative, but it does give 
some idea of how well each package 
handles multitasking. 

Just starting Procomm reduced the up¬ 
date speed from very fast to slow. The 
speed did not change when text was 
being received and displayed, but during 
a file transfer my control program ap¬ 
peared to stop. 

Starting Dynacomm noticeably re¬ 
duced the update speed, but it still exe¬ 
cuted at a reasonable rate. During the re¬ 
ceipt and display of text, the speed 
dropped to slow, and during a file trans¬ 
fer the speed was very slow. 

Starting Term also slowed the update 
speed of my control program. The update 


speed did not change when text was re¬ 
ceived and displayed. For some reason 
the speed actually increased during file 
transfer. 

Crosstalk and APE have the same per¬ 
formance profile. Starting them had no 
noticeable effect on my control program. 
During the receipt and display of text the 
control program’s update speed noticea¬ 
bly slowed down. Update speed during a 
file transfer was faster than when text 
was displayed. 

Dynamic data exchange. Dynacomm, 
Crosstalk, and APE all support Win¬ 
dows’ Dynamic Data Exchange protocol. 
This protocol lets two Windows pack¬ 
ages pass data and commands back and 
forth. Unfortunately, I was not able to 
test how well these packages support 
DDE. 

Problems. I found that Dynacomm 
and APE sometimes hung my PC. Dyna¬ 
comm didn’t do it very often and always 
as I was exiting the package. APE’s 
hangs seemed to come from errors in 
script files. Once I corrected the errors, 
my system stopped hanging. 

APE also had a problem when marking 
more than 26 columns of text. After 26 
columns the marked text did not invert 
correctly. It still copied onto the clip¬ 
board correctly, but the display was 
messed up. 

I also had a minor problem with 
Term’s VT100 terminal emulation. In the 
keypad application mode the keypad * 
key did not send the correct escape se¬ 
quence; all it sent was an Also, the 
extended insert, home, page up, end, and 
page down keys did not send anything. 
The extended delete and arrow keys 
worked correctly. 


Scripting 

To evaluate the scripting capability of 
the packages, I constructed several 
scripts making heavy use of data capture, 
string manipulation, and user interaction 


features. All the packages have a rich set 
of string functions and support both 
string and integer variables. Except for 
APE, they all provide a loop construct 
and support block statements. Looping in 
APE is done via if and goto statements. 

I found that the lack of block state¬ 
ments in APE forced me to create some 
clumsy looking scripts with lots of goto 
statements. In fact, I found that APE had 
both the weakest and strongest language. 
It was weak because it was difficult or 
clumsy to do certain things, like get the 
line just sent by my host into a variable. 
It was the strongest because there were 
things that I could do only with APE, 
like execute a special script after five 
minutes of no keyboard activity or exe¬ 
cute two scripts at once. 

Host interaction. In all the packages 
host interaction is done by a set of com¬ 
mands that sends characters to the host 
and suspends execution until a set of 
conditions is met. The send commands 
are all relatively simple. A string of char¬ 
acters is specified in the form of a con¬ 
stant or a variable. The suspend com¬ 
mands offer a much richer set of alterna¬ 
tives. Table 6 lists the types of waits that 
control interaction with the host. 

In all these suspend commands you 
can also specify a timeout value. How¬ 
ever, Dynacomm does not provide a way 
to determine if the script continuation re¬ 
sulted because the wait condition was 
met or the timeout time had elapsed. 

Term has two sets of wait commands. 
The standard Wait does not display in¬ 
coming characters in the terminal win¬ 
dow. The Dwait command will display 
the characters. Term has the serious limi¬ 
tation that you cannot enter characters 
via the keyboard while the script is wait¬ 
ing. I needed this capability because line 
noise sometimes garbled characters, 
which caused the script to get out of sync 
with the host. I also needed it while I 
was developing scripts. 

Crosstalk and APE both have the use¬ 
ful feature that you need not exactly 
specify the string to wait for. Both pack¬ 
ages have a set of wild characters. In 
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None of the packages 
provides very good 
debugging tools. 
Term does not 
provide anything. 


Crosstalk you can match any letter (in¬ 
cluding upper- or lowercase), digit, or 
white space character, but you still need 
to know how many characters are in the 
string. APE allows you to match any 
character, any number of characters, or 
any number of numeric characters. 

All the packages but APE also have a 
way to accept the next character or line 
sent by the host and place it into a script 
variable. APE required that I wait for the 
carriage return character and then copy 
the line off of the terminal window and 
into a variable. I found this clumsy. 

All the packages but Crosstalk also 
have a feature similar to an interrupt 
handler. The incoming characters are 
continuously scanned. When the target 
string is received, normal script execu¬ 
tion is suspended, the interrupt command 
is executed, and the script continues 
from where it left off. Procomm allows 
only the Send command in its interrupt 
handler, while Dynacomm and APE al¬ 
low any script command to be executed. 

Term cannot watch incoming charac¬ 
ters, but can monitor the COM port and 
react if the carrier signal is dropped. 

Crosstalk does not have this interrupt 
feature, but it does have a feature that 
lets you wait for multiple sets of strings 
and execute a different script command 
depending on which string was received. 

User interaction. All the packages 
provide some mechanism to interactively 
query for text and load the input into a 
string variable. Dynacomm, Crosstalk, 
and APE all allow you to build MS Win- 
dows-style dialog boxes. Dynacomm and 
Crosstalk allow you to build very com¬ 
plex dialogs, with multiple inputs and 
control of their positions in the dialog 
box. APE allows only a single input in 
the dialog box and no control over its 
position. 

Procomm and Term have their own 
style of interaction, which was also easy 
to use, if different from MS Windows. 

All the packages also have functions 
to send text directly to the terminal win¬ 
dow without a dialog box. Text attrib¬ 
utes are set by embedding the control se¬ 
quences that select those attributes in the 


text. I found this useful for creating 
color-coded displays. Dynacomm’s more 
extensive attribute control allowed me to 
create the most colorful displays. 

APE’s flash command will flash the 
title bar or APE icon until the APE win¬ 
dow is activated. This allowed me to 
start a script and then minimize APE or 
select another window and still have an 
indication when the script finished. 

File interaction. All the packages 
have some form of file I/O. Procomm is 
limited to two open files, APE to five, 
Dynacomm to 10, and both Term and 
Crosstalk to 20. Dynacomm, Term, and 
Crosstalk allow random I/O to any char¬ 
acter position in the file. APE allows 
random I/O to any line in the file. Dyna¬ 
comm has something called tables, 
which can be based on a file. This allows 
you to overlay some form of structure on 
the file, which made reading it much eas¬ 
ier for me. 

Automatic script generation. Only 
Procomm and APE provide a utility for 
automatically generating a script. These 
utilities create a file and then record the 
characters sent to the host in send com¬ 
mands and the characters received from 
the host in wait commands. These scripts 
are not perfect; you must edit them to 
remove variable text like dates and times 
and to add checks for alternative re¬ 
sponses. However, they are an excellent 
starting point. 

Debugging. None of the packages pro¬ 
vides very good debugging tools. Term 
does not provide anything. The others at 
least make an effort to help debug 
scripts. 

Procomm and Crosstalk provide a 
trace command. This causes all script 
commands to print in the terminal win¬ 
dow as they are executed. In Procomm 
the lines are printed with the format 

LINE N: <line> 

where N is the line number and <line> is 
the text of the line. In Crosstalk only the 
line number is printed, with the format 

[N] 

This makes it hard to debug scripts that 
are also constructing forms or tables in 
the terminal window. It also makes it dif¬ 
ficult to read text sent by the host. Pro¬ 
comm tries to help by displaying the de¬ 
bugging lines in a contrasting color, but 
that isn’t possible under Windows, so 
the lines are printed in the default text 
color. 

Dynacomm and APE have two script 
debugging aids. Each has a command 


that causes script lines to display in the 
status (Dynacomm) or message (APE) 
line as it is executed. Dynacomm also 
has a debug command that causes a copy 
of each script line to be written to the 
debug file as it executes. APE can also 
write all characters sent to or received 
from the host and the text displayed on 
the message line to a log file. 

Script examples. All the packages 
provided example scripts. Procomm’s 
and Crosstalk’s were excellent. Dyna¬ 
comm provided lots of scripts, but the 
Jack of good comments made them only 
marginally useful. APE’s examples were 
also not very useful. Some of Term’s 
scripts were well commented and some 


Test script summary. A major prob¬ 
lem I had with Procomm, Term, and 
Crosstalk was that the function that accu¬ 
mulates an incoming line of characters 
will only stop after a specified number of 
characters or a carriage return is re¬ 
ceived. I needed it to stop after receiving 
a special two-character sequence. 
Dynacomm’s function let me do this, 
and, as I mentioned above, APE’s tech¬ 
nique of waiting for a string and then 
copying the line off of the terminal win¬ 
dow also worked. 

Despite their debugging aids I found it 
very hard to debug the scripts. The easi¬ 
est was Crosstalk; both Dynacomm and 
Crosstalk compile the scripts, which 
made things easier. However, while 
Dynacomm’s compile time error report¬ 
ing was very good, its runtime error re¬ 
porting was not. It does not report the 
error’s location, and the reported error 
codes are not explained anywhere. 
Crosstalk had very good compile-time 
and runtime error reporting. 


I was able to get my 
test scripts running 
under all the packages, 
but I found Term and 
APE the hardest. 


I was able to get my test scripts run¬ 
ning under all the packages, but I found 
Term and APE the hardest. I also found 
bugs, or at least what appeared to be 
bugs, in Term and APE. In Term I could 
not get a series of if-then-else statements 
to work. I had to use a series of if state¬ 
ments. APE had a tendency to hang my 
system if I executed a script with errors 
in it. 
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Support 

All the technical support groups did a 
good job of answering my questions. 
When I called, I was connected quickly 
and did not spend a lot of time on hold. 

If the people I talked to could not an¬ 
swer my question and said they would 
call back, they usually did. None of the 
companies have a toll-free number, 
which I find disappointing. 

However, I am left with an overall 
negative impression of DataStorm’s sup¬ 
port philosophy for Procomm. First, the 
manual explained that I was allowed 
only five free phone calls to Data¬ 
Storm’s technical support group during a 
90-day period that started with my first 
call. After that I could purchase ex¬ 
tended support of 10 calls in six months 
or 20 calls in one year. I can accept a 
limited time period for free support 
(APE has 60 days of free support), but 
not a limited number of calls. Second, 
the phone number listed in the manual 
for the technical support line was wrong. 
I found the correct number (313/875- 
0530) when I called DataStorm’s busi¬ 
ness office to complain that I could not 
get through to technical support. The 
original phone number was either busy 


or had a DataStorm recording listing the 
technical support hours. There was noth¬ 
ing about a new phone number. Finally, 
when I called to get a new manual, I was 
told that one would be sent within a 
week. A week later I received a letter 
telling me to return the defective manual 
first. 


My choice 

I view Procomm and Term as bridge 
products. If I were running under both 
Windows and DOS, I might choose Pro¬ 
comm just so I wouldn’t have to learn a 
new terminal emulator. Term not only 
runs under Windows and DOS, but also 
under Unix and Zenix, MAC, VMS, and 
BTOS (Unisys). Again, if I were running 
under Windows and one of these other 
systems, I might choose Term. Since all 
my systems are running Windows, I pre¬ 
fer a product that makes full use of Win¬ 
dows. 

I have selected APE as my emulator of 
choice primarily because it let me build 
my own terminal emulation. I also like 
its fast redisplay of its large scrollback 
buffer and the ease of switching to full¬ 
screen standard DOS applications. Its 
tendency to hang my system when I get 


script errors is a problem I can tolerate 
(just barely). 

If I didn’t need customizable terminal 
emulation, I probably would have chosen 
Crosstalk. Crosstalk’s scrollback buffer 
redisplay is slow, and switching to full¬ 
screen DOS applications from Crosstalk 
is harder than from APE, but I never ex¬ 
perienced any system hangs when run¬ 
ning it. 

Dynacomm is also a good product. It 
has the best user interface and works 
with a network, but I found its scrollback 
buffer size way too small, and I didn’t 
like the way it slowed down applications 
running in other windows. 

Windows warning 

Microsoft released a version of MS 
Windows (286 and 386) with a buggy 
version of comm.drv. This causes incor¬ 
rect handling of Xon/Xoff flow control, 
which in turn can cause other problems. 
The incorrect version can be identified 
by checking the date and size of the 
comm.drv file on the original distribution 
disks. If the file is dated 9/7/88 or is 
4,484 bytes long, you have the buggy 
version and need to call Microsoft for a 
replacement. 
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NEW PRODUCTS 


Contact or send releases to Nancy Hays, Computer, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720; Compmail+ , n.hays 


HP floods market with announcements 


Hewlett-Packard has announced 24 
new computer systems, including entry- 
level, midrange, and high-end models in 
the HP 3000 and HP 9000 product lines. 
The systems feature the company’s Pre¬ 
cision Architecture RISC design. 

The HP 3000 Series 890/200 and HP 


Hewlett-Packard has built the HP 9000 
Series 300 Models 345 and 375 around 
Motorola’s 50-MHz 68030 microproces¬ 
sor. Like other Series 300 models, the 
new workstations run Unix software. 

Model 345 supports 4-16 Mbytes of 
main memory, while Model 375 comes 
with 8 Mbytes of memory expandable to 
32 Mbytes (128 Mbytes in the future). 
Model 375 has up to 12 expansion slots. 


Maspar Computer has announced the 
MP-1 Family of data parallel computers, 
consisting of the MP 1100 Series and MP 
1200 Series with a total of eight configu¬ 
rations. They apply up to 16,384 proces¬ 
sors and reportedly deliver up to 30,000 
MIPS and 1,500 Mflops of performance. 

The new computers use Unix and X 
Windows-based networking. 


Voxel View handles 3D data 

Vital Images claims that its Voxel 
View interactive volume-rendering soft¬ 
ware allows the visualization and ma¬ 
nipulation of three-dimensional data sets 
in real time. The software contains op¬ 
tions to rotate, color, and section 3D 
data, as well as options to adjust trans¬ 
parency, lighting, and other rendering 
features. 

The mouse-driven program features a 
pictorial data catalog, pop-up menus, and 


9000 Model 870/200 have two proces¬ 
sors and rely on symmetric multiproces¬ 
sing. The HP 3000 uses the MPE/XL op¬ 
erating system, while the HP 9000 uses 
the HP-UX processing system. Existing 
applications run on the new models. 

The Series 980/200 is scheduled for 


Model 345 also has an optional 200- 
Mbyte integrated disk drive for $3,600. 

Model 345 costs around $9,000 and 
reportedly can process up to 12 MIPS. 

Model 375 costs around $22,000. It is 
designed for upgrading to the Motorola 
68040 microprocessor when available. 
The upgrade will cost $2,000. 
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According to the company, the units ’ 
do not require special cooling or hous¬ 
ing. 

Prices begin at $170,000 for a 1,024- 
processor MP 1101 and range up to 
$810,000 for a 16,384-processor MP 
1216. 

Reader Service 33 


sets in real time 

graphical control of rendering parame- 

Voxel View runs on workstations from 
Silicon Graphics Computer Systems. It 
comes on a 0.25-inch tape cartridge. The 
company recommends a minimum of 16 
Mbytes of main memory. 

Voxel View ranges in price from 
$12,000 to $40,000. 
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delivery at the end of 1990. It will re¬ 
portedly provide more than 100-transac- 
tions-per-second performance. It will 
cost around $1,090,000. 

Model 870/200 reportedly offers up to 
95 MIPS of performance. 

980/200: Reader Service 30 
870/200: Reader Service 31 


Yarc intros parallel 
coprocessor 

Yarc Systems has introduced the Pro- 
tran PC-AT Coprocessor System, a paral¬ 
lel coprocessor. It features a T800 
transputer-based parallel processing sys¬ 
tem, zero wait state performance, a PC 
bus interface with peak I/O speeds in ex¬ 
cess of 1 Mbps, compatibility with Inmos 
B004 software, up to 40 Mbytes of RAM 
on a single board, and from one to four 
transputers per board (with link adaptor). 

The Protran works in IBM PC-AT or 
80386-compatible computers and oper¬ 
ates at 20 or 25 MHz. 

Prices begin at $2,295. 
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Integrity S2 relies on 
RISC, fault-tolerance 

Tandem Computers employed RISC 
technology and a fault-tolerant platform 
to produce the Unix-based Integrity S2 
system. The new system conforms to 
AT&T’s Unix System V Interface Defi¬ 
nition, but the company added its own 
error prevention and correction features. 

The system incorporates a 32-bit 
R2000 RISC microprocessor from Mips 
Computer Systems, running at a clock 
rate of 16.67 MHz. It uses the Nonstop- 
UX operating system. 

Integrity 2 models are scheduled for 
the first quarter of 1990. Prices start at 
$172,000 for the entry-level system; 
$198,000 for the midrange model; and 
$248,000 for the high-end model. 
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HP bases workstations on 50-MHz 68030 


MP-1 Family applies massive parallelism 
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Tandon debuts 486, 
laptop PCs 


Tandon offers an EISA-compatible PC 
based on Intel’s 25-MHz 80486 micro¬ 
processor. Tandon 486 models come 
with a 1.2-Mbyte disk drive and no fixed 
disk drive (Model 1), a 110-Mbyte IDE 
fixed disk drive (Model 100), a 330- 
Mbyte SCSI fixed disk drive (Model 
300), or a 670-Mbyte fixed disk drive 
(Model 600). 

Tandon 486 PCs come with the 
company’s Power Poster unit and Multi¬ 
cache 64-Kbyte SRAM cache. The stan¬ 
dard 2-Mbyte memory can be upgraded 
to 64 Mbytes of 64-bit memory. 

Prices for the Tandon 486 range from 
$9,000 to $25,000 for a 760-Mbyte hard 
disk model with a 650-Mbyte optical 
disk drive. 

The Tandon LT/386, based on the 
80386SX microprocessor, operates at 16 
MHz and has a 3.5-inch 1.44-Mbyte 
floppy disk drive, a 40-Mbyte hard disk 
drive, and VGA. The 80286-based LT/ 


Tandon’s LT/286 and LT/386 laptops weigh 14.5 pounds. 


Factory System targets make-to-order manufacturers 


Factory Automation and Computer 
Technologies has aimed its turnkey fac¬ 
tory management and control system, the 
Factory System, at make-to-order manu¬ 
facturers. The Factory System executes 
manufacturing tasks and manages re¬ 
sources on the shop floor. 

The system uses finite capacity sched¬ 
uling to allocate resources, provide 


“what if’ scenarios, and project future 
work-flow patterns and possible bottle¬ 
necks. It also provides documentation of 
activities from order to shipment, com¬ 
parison of actual versus planned activi¬ 
ties, validation of standards, and historic 
performance calculations. 

The Factory System operates on PCs. 
Users can run the system on a single unit 


or up to 255 nodes. The database resides 
in RAM on the PC cluster and is backed 
up on the hard disk drive. 

The multiprocessor computing plat¬ 
form, expandable to 255 nodes, costs 
$25,000. The software is priced per node 
by computer type, ranging from $1,875 
per node for an 8086 system to $7,500 
per node for an 80386 system. 


Easy Data offers 486-based 

Easy Data Computer Products offers 
the Model 425, which incorporates 
Intel’s 25-MHz 80486 microprocessor 
and Easy Data’s Burst memory bus. The 
new PC supports a floating-point 
coprocessor; a cached shadow RAM for 
the system BIOS; a choice of Phoenix, 
Award, or AMI ROM BIOS; and Unix, 


PC with Burst memory bus 

Xenix, and MS-DOS. 

Model 425 comes with a 300-Mbyte 
ESDI hard disk drive, a disk caching 
controller, optional CD-ROM, and a re¬ 
movable optical drive. 

Easy Data’s Model 425 costs $8,999. 
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Profacs manages 
production information 


Integrated Technologies’ Profacs 
monitors production in manufacturing 
plants. It allows collection of data such 
as production, counts, times, and user- 
defined variables. Data can be supplied 
by manual data entry, relays, sensors, 
programmable controllers, machine-tool 
controllers, and test equipment. 

Job summary data is updated plant¬ 
wide and compared to job schedules. Ex¬ 
ception reports keep plant management 
informed of problem jobs and scheduling 
conflicts. 

Users can access historical production 
information through the SQL database 
and generate reports and graphical analy¬ 
sis for evaluation. 

Contact the company for pricing. 


286 operates at 12 MHz and has a 3.5- 
inch 1.44-Mbyte floppy disk drive, a 20- 
Mbyte hard disk drive, and EGA. 

The laptops come standard with 1 
Mbyte of RAM and weigh 14.5 pounds. 


The LT/286 costs $3,874 and the LT/ 
386, $4,429. 


Tandon 486: Reader Service 37 
Laptops: Reader Service 38 


LAN-Fax Gateway works with TCP/IP or OSI networks 


Frontier Technologies has announced 
that the LAN-Fax Gateway product al¬ 
lows users on TCP/IP or OSI networks to 
transmit and receive facsimiles. It con¬ 
forms with the CCITT requirements, in¬ 
cluding the T.4 and T.30 protocols. 

LAN-Fax Gateway consists of a LAN- 
Fax card with support for Ethernet and 


facsimile. The card has an on-board 
80186 CPU. The software consists of 
facsimile manipulation software and ei¬ 
ther TCP/IP or OSI network software. 

The hardware costs $995, while the 
software is $495. 
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Company, Model, Function 

Comments R.S. No. 

Advanced Micro Devices 
Am29000 

Microprocessor 

A 33-MHz version of the 32-bit RISC microprocessor, now available for sampling. Claims 22 120 

MIPS performance. Pin-compatible with the current family of 16-, 20-, and 25-MHz versions. 

Comes in a ceramic PGA. Production in first quarter 1990. Cost (1,000s): $280. 

Gould AMI 

GC100K 

Gate array 

A 100,000-gate gate array in the GC Series of CMOS ASIC arrays. Offered in tandem with a li- 121 
brary of digital macrocells for implementing logic functions. Comes in 160-pin or 196-pin 
quad flat packs, with other packaging scheduled for first quarter 1990. Cost (10,000s): $99 
(160 pins) or $105 (196 pins). 

Hitachi America 
HM624256/7 

SRAMs 

Two 1-Mbit SRAMs configured 256Kx4, with access times of 35 and 45 ns. Now available in 122 

volume production. HM624256 has common I/O and output enable; HM624257 has separate 

I/O. HM624256 comes in 28-pin plastic SOJs. HM624257 comes in a 32-pin plastic SOJ. Cost 
(500s): $190 (45 ns) or $210 (35 ns). 

Motorola 

68HC711E9 

Microcontroller 

An 8-bit microcontroller derived from the 68HC11 family. Features 12 Kbytes of EPROM, 123 

512 bytes of EEPROM, 512 bytes of RAM, a 16-bit timer, a serial peripheral interface, a serial 
communications interface, 38 I/O lines, and Stop and Wait modes. Samples in 52-pin ceramic 
quad window packages. Production in 52-pin PLCCs in second quarter 1990. Cost: $150. 

Philips Components- 
Signetics 

PML2552 

PLD 

A CMOS version of the company’s programmable macro logic device, with 2,500 gates. 124 

Provides multimaster handshake capabilities. Has two banks of eight D flip-flops connected 
directly to input pins of the part, plus 16 D flip-flops whose Q outputs connect directly to the 
bidirectional I/O pins of the chip. Has two banks of 10 buried J-K flip-flops. Cost: $18. 

Precision Monolithics 
SSM-2139 

Op amp 

A monolithic audio bipolar operational amplifier. Internally compensated for gains of 3 and 125 

above. Draws 4 mA of supply current total for both amplifiers. Comes in an 8-pin pinout or 
epoxy DIP over the extended industrial temperature range. Cost (100s): $1.85. 

Sharp Electronics 

16-Mbit PROM 

PROM 

A 16-Mbit mask programmable ROM with a proprietary flat cell structure and a bank-select 126 

architecture. Incorporates a sense amplifier. Uses a die measuring 11.97 mm x 11.10 mm. Al¬ 
lows for high-density storage with access times up to 200 ns at 5V. Comes in a 128-pin quad flat 
pack. Pricing not set. 

Standard Microsystems 
FDC37C65B 

Controller 

A replacement for the FDC37C65B floppy disk controller. Supports data rates up to 1 Mbps. 127 

Uses a licensed FDC765 core controller and the company’s data separator technology. Comes 
in 40-pin DIP and 44-lead PLCC packages. Cost (10,000s): $5.50. 

Styra Semiconductor 
ST82C21 HEAT Styraset 
Chip set 

A 16-MHz three-chip set that replaces Chips and Technology’s CS8221 NEAT chip set. Com- 128 
patible with IBM’s PC AT and Intel’s 80286. Supports systems up to 20 MHz. Available in first 
quarter 1990. CPU/bus controller, page interleave and EMS memory controller, and data/ad¬ 
dress buffer implemented in 1.2-micron CMOS technology. Cost (10,000s): $19.95. 

Texas Instruments 
TIBPSG507, TIBPLS506 
PLDs 

Programmable logic devices — sequencers. The 13x80x8 TIBPSG507 programmable se- 129 

quence generator has an on-chip counter and a 58-MHz max clock rate. The 13x97x8 

TIBPLS506 programmable logic sequencer has 16 on-chip state registers and a 50-MHz max 
clock rate. Both come in 24-pin, 300-mil ceramic DIPs. Cost (1,000s): $15 each. 

Texas Instruments 
Prologic 

Software 

A PC-based software tool for TI programmable logic device design, test, and implementation. 130 
Allows design in three formats: truth tables. Boolean equations, and state diagrams. Uses the 
resulting JEDEC file to create a functional device model to execute test vectors. Available free 
(as SRPU001) through March 1990 from TI Customer Response Center at (800) 232-3200. 

Texas Instruments 

SN74BCT2423 

Transceiver 

A 16-bit, cascadable bus-interface that integrates bidirectional transceiver, latch, and multi- 131 
plexer/demultiplexer functions. Has three 16-bit I/O ports in the transceiver. Draws 190 mA 
max enabled and 50 mA max disabled. Operates from 0-70 degrees C. Comes in a 68-pin PLCC. 

Cost (1,000s): $6.48. 

Vitesse Semiconductor 
VSC30K 

Gate array 

A 30,000-gate GaAs gate array, newest in the Fury Series. Features 30,528 two-input NOR 132 

gates with 100-percent gate utilization. Has 256 signal pins configurable to ECL, TTL, and 

GaAs I/O levels. Typical power dissipation of 8-12W. Comes in a 344-pin LCC. Prototype 
shipments in first quarter 1990. Prices vary. 
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CALL FOR PAPERS 



11th Real-Time 
Systems Symposium 

December 5-7,1990 
Orlando, Florida 


Sponsored by the IEEE Computer Society TC on Real-Time Computing 

The symposium will explore computer systems and communication networks used in real-time 
applications. Both formal paper and panel discussion sessions are planned. Papers in areas related 
to the theory, design specification, verification, implementation, and evaluation of real-time sys¬ 
tems are sought. Of particular interest are papers that deal with case studies, experimental 
results, testbeds, and performance data from operational and prototype systems. 


General Chair 

Doug Locke 
IBM-M/S 409 
Systems Integration Division 
6600 Rockledge Dr. 

Bethesda, MD 20817 
(301) 493-1496 
cdl@cs.cmu.edu 

Treasurer 

Walter Heimcrdinger 

Local Arrangements Chair 

Earl Swartzlander 


Program Chair 

Jane W. S. Liu 


Program Committee 

Flaviu Cristian 

Keith Marzullo 

Karen Gordon 

A1 Mok 

Andrew Grimshaw 

Krithi Ramamritham 

Farnam Jahanian 

James G. Smith 

David Jameson 

Hide Tokuda 

Insup Lee 

Horst Wedde 

John Lehoczky 

Nancy Lynch 

Wei Zhao 


Paper Submission 

To submit papers, send five (5) copies of double-spaced manuscripts, 5000 words or less in 
length, by May 1, 1990 to: 

Jane W. S. Liu 
University of Illinois 
Department of Computer Science 
1304 West Springfield Avenue 
Urbana, Illinois 61801 


(217)333-0135 
janeliu @ cs.uiuc.edu 


Important Dates 


Paper Due: 

May 1,1990 

Notification of Paper Acceptance: 

July 15, 1990 

Camera Ready Copies Due: 

September 1,1990 
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Microsystem Announcements 


Company, Model, Function Comments R.S. No. 


Analogic 

DAS-12 family 

Data acquisition boards 


Engage Communication 

Syncrouter 

Router 


Educorp 
CD-ROM 4.0 
Software 

Commax Technologies 
Excell 486-25 
Motherboard 

Commax Technologies 
Excell 386-33C 
Motherboard 

Head Start Technologies 
LX-CD 

CD-ROM computer 

Head Start Technologies 
Head Start III-CD 
CD-ROM computer 

Intel 

iSBC 386/12S 
CPU board 


OTB Systems 
OTB 386 Tower 
PC 


Output Technology 
Lasermatrix 1000 
Laser printer 

Real Time Devices 
DG24, DG96 
Digital I/O cards 


RGB Spectrum 
RGB/View 500 
Video controller 


Touchbase Systems 
Worldport 2496i-T 
Fax/modem 


A family of 12-bit, multifunction data acquisition boards for the IBM PC AT and compatibles. 135 
Features 16 single-ended and eight differential analog inputs and autocalibrating 12-bit 
ADCs, two deglitched DACs with optional buffer memory, a digital I/O port, and timers. 

HSDAS-12 samples at 400 KHz; MSDAS-12 at 200 KHz; and LSDAS-12 at 100 KHz. Cost: 

$2,295 for HSDAS; $1,995 for MSDAS; $1,795 for LSD AS. 

A router that allows interconnection of remote Appletalk networks. Supports Appletalk Phase 136 
2. Uses a direct-memory-access technique for high-speed data handling. Includes an Intel 
8088, 32 Kbytes of SRAM (expandable to 96 Kbytes), 32 Kbytes of EPROM (expandable to 96 
Kbytes), and 256 bytes of EEPROM. Cost: $1,895. 

A Macintosh CD-ROM disk of public domain software containing more than 600 Mbytes of 137 
guaranteed virus-free shareware, including more than 150 Mbytes of HyperCard stacks. Uses a 
HyperCard interface. Cost: $199; $79 for upgrades. With Denon CD-ROM drive, $849. 

A 25-MHz motherboard based on Intel’s 80486 processor. Hasan Intel 82385 cache controller 138 
with 32 Kbytes of cache memory, built-in math coprocessor, and a burst mode interleave main 
memory system. Claims more than 10 MIPS performance. Cost (100s): 3,995. 

A motherboard based on Intel’s 33-MHz 80386 processor. Has an 82385 cache controller with 139 
32 Kbytes of cache memory, 95-percent cache hit rate, 32-bit memory bus, page mode main 
memory, 8-MHz AT bus, and eight expansion slots. Cost (100s): $1,695. 

A CD-ROM computer that comes with an 8088-1 CPU, 5.25-inch 680-Mbyte CD-ROM drive, 140 
40-Mbyte hard disk drive, 1,44-Mbyte/720-Kbyte autodetect 3.5-inch disk drive, VGA card, 
stereo headphones, mouse, compact disks, and software. Cost: starts under $2,000. 

A CD-ROM computer that comes with an 80286 CPU, 5.25-inch 680-Mbyte CD-ROM drive, 141 
40-Mbyte hard disk drive, 1,44-Mbyte/720-Kbyte autodetect 3.5-inch floppy disk drive, 
built-in VGA, stereo headphones, modem, mouse, compact disks, and software. Cost: $2,995. 

A Multibus I board combining the functions of a CPU board and a dedicated peripheral control- 142 
ler. Incorporates a 20-MHz 386 CPU with on-board SCSI supporting a synchronous data rate 
of 5 Mbytes/s and an asynchronous rate of 2 Mbytes/s. SCSI data transfers buffered in on-board 
FIFOs. Comes in four memory configurations. Cost: starts at $4,900 (1 Mbyte). 

A computer based on Intel’s 20-MHz 80386. Features internal EFI power protection and the 143 
company’s proprietary Thermokinetic cooling. Comes with a three-year warranty. Base sys¬ 
tem includes a floor-standing tower with a 3.5- or 5.25-inch drive, six drive bays, eight expan¬ 
sion slots, 1 Mbyte of 80-ns RAM, an 85-Mbyte Seagate SCSI hard drive, monitor, and 101-key 
keyboard. Cost: $7,000. 

A continous-form desktop laser line printer. Claims a consistent speed of 1,000 1pm and 15 144 

ppm. Features a 3.5- to 9.5-inch adjustable tractor feed, a BP100A ASIC controller chip, a scal¬ 
able font, and two Hewlett-Packard compatible font card slots. Cost: $7,995. 

Digital I/O cards for the IBM PC XT and AT bus. Based on the 10-MHz 9255 programmable 145 
peripheral interface chip, which allows three modes of operation: simple, strobed, and bidirec¬ 
tional I/O. Have optional buffers, with jumper-selectable direction. Cost: $95 for the 24-line 
DG24; $225 for the 96-line DG96. 

A video windowing display controller that integrates real-time video with computer-gener- 146 
ated text and graphics. Supports high-resolution displays on workstations using the VME bus 
and a 9Ux400 mm or 9Ux280 mm form factor. Accepts input from any camera, tape recorder, 
live television, interactive video disk, or video teleconferencing system. Cost: $9,995. 

An internal modem for Toshiba laptop computers (with A-type expansion slot). Features a 147 
9,600-bps Group III fax and a 2,400-bps data modem. Detects incoming calls as fax or modem 
and switches to correct part of software. Saves faxes to disk; routes data calls to a bulletin board 
system. Background or foreground operation. Cost: $699. 


92 


COMPUTER 







CONFERENCES 


Editor: Edmund L. Gallizzi, Computer Science Dept., Eckerd College, St. Petersburg, FL 33733; (813) 864-8272; Compmail, e.gallizzi 


Compcon Spring 90 to feature key speakers, major award presentations 


Four keynote speeches, the presenta¬ 
tion of prestigious IEEE Computer Soci¬ 
ety awards, and an extensive technical 
program highlight the agenda for 
Compcon Spring 90, slated February 26 
to March 2 at San Francisco’s Cathedral 
Hill Hotel. 

Kenichi Miura of Fujitsu America is 
general chair and Roger Anderson of the 
Lawrence Livermore National Labora¬ 
tory is program chair of the event, spon¬ 
sored by the IEEE Computer Society. 

Andy Rappaport, president of the 
Technology Research Group, and Ed 
Davis, president and CEO of Raynet 
Corp., will deliver keynote talks Tues¬ 
day, February 27. Joel Bimbaum, who 
heads Hewlett-Packard’s Information 
Architecture Group as vice president and 
general manager, will speak Wednesday, 
February 28, and Cliff Stoll, author of 
The Cuckoo’s Egg, will take the podium 
Thursday, March 1. 

Rappaport will talk on “The Impact of 
Designers and Consumers of Nearly Free 
Semiconductors in the 1990s,” present¬ 
ing historical data on semiconductors 
during the past three decades and ex¬ 
trapolations to the year 2001. 

In his address, Davis will focus on how 
the Global Village is coming of age 
through communications technology ad¬ 
vances in “The Global Village in the 


1990s — Networking the Home and The 
Office.” 

Bimbaum will speak on “Analysis and 
Extrapolation of RISC, CISC, and Per¬ 
formance Architectures,” sharing his in¬ 
sights and providing information per¬ 
spectives on this highly competitive 
field. 

In his talk, “Stalking the Wily Hacker,” 
Stoll will share his experiences in track¬ 
ing criminal hackers through hundreds of 
military computers and provide insight 
on security problems. 

The awards ceremonies February 28 
will feature the presentation of this year’s 
W. Wallace McDowell Award to Edward 
Eichelberger and Tom Williams of IBM; 
Computer Pioneer Awards to IBM’s John 
Cocke and retired IBM researchers Ralph 
Palmer and James A. Weidenhammer; 
special Computer Pioneer Awards to 
Mina S. Rees, Marshall C. Yovits, and 
posthumously to F. Joachim Weyl; the 
Computer Entrepreneur Award to Gene 
Amdahl, chairman and president of An- 
dor Systems; the Richard E. Merwin Dis¬ 
tinguished Service Award to Stanley 
Winkler, guest research worker with the 
US National Institute of Standards and 
Technology; and various service certifi¬ 
cates. 

Rees, retired City College of New York 


graduate school president; Yovits, pro¬ 
fessor of computer and information sci¬ 
ence at Indiana University-Purdue Uni¬ 
versity in Indianapolis; Weyl, who 
served as dean of sciences and mathemat¬ 
ics and acting president of New York’s 
Hunter College; and the late Gordon D. 
Goldstein, who received his special Com¬ 
puter Pioneer Award 17 days before he 
died last May 13, are being honored for 
their work with the US Office of Naval 
Research. The posthumous award to 
Weyl will be accepted by his widow, 
Martha Weyl Kenworthy. 

Allen Newell of Carnegie Mellon Uni¬ 
versity will receive the IEEE’s Emman¬ 
uel R. Piore Field Award for outstanding 
achievement in information processing. 
The winner of the Gordon Bell Prize will 
also be announced at Compcon. 

Eight day-long tutorials will be pre¬ 
sented, half on Monday, February 26, and 
the other half on Friday, March 2. The 
multitract technical program will feature 
papers on architectures, workstations, 
object-oriented programming, database 
systems, microprocessors and embedded 
systems, and IC design and test, among 
other topics. 

For additional information and regis¬ 
tration instructions, see the ad on pp. 
16A-H of the January 1990 issue of Com- 


Prospects for fully 


autonomous robotic systems debated at workshop 

and Suresh B. Marapane, University of Tennessee, Knoxville 


Clint R. Bidlack, ChuXin Chen, 

The possibilities for developing com¬ 
pletely autonomous robotic systems 
prompted debate among a panel of ex¬ 
perts at the Workshop on Intelligent 
Robotic Systems: Design and Applica¬ 
tions, held November 7 in Philadelphia. 

The event was held in cooperation with 
the IEEE Computer Society and IEEE 
Systems, Man, and Cybernetics Society 
and in conjunction with the Society of 
Photooptical Instrumentation Engi¬ 
neer’s 1989 Symposium on Advances in 
Intelligent Robotics Systems. 

Mohan M. Trivedi of the University of 
Tennessee, Knoxville, organized and 
chaired the event. 


The program featured nine presenta¬ 
tions followed by a panel discussion en¬ 
titled “Accomplishments and Challenges 
in Developing Intelligent Robots.” The 
presentations were organized into three 
sessions: “Autonomous Navigation,” 
“Information Analysis: Languages, 
Models, and Algorithms,” and “Intelli¬ 
gent Robotic Systems.” Each session in¬ 
cluded three, 40-minute talks, providing 
the speakers ample time to describe their 
research and results and giving the audi¬ 
ence time to ask questions. 

The presentations and panel discus¬ 
sion drew participants from numerous re¬ 
search laboratories. The nine presenta¬ 


tions provided attendees with an overview 
of a combination of research projects 
being performed at university, industrial, 
and government labs. The panel discus¬ 
sion provided a stimulating dialogue on 
past, present, and future research and de¬ 
velopment activities in the field. 

Panel discussion. Trivedi moderated 
the panel discussion, on “Accomplish¬ 
ments and Challenges in Developing In¬ 
telligent Robots.” Panelists were Peter K. 
Allen, Avinash C. Kak, Paul S. Schenker, 
Ramesh C. Jain, and Kitcha S. Ganapa- 
thy. The panelists briefly presented their 
views of what has been achieved in the 
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field of intelligent robotics, described the 
important challenges for the future, and 
debated whether the body of researchers 
is addressing those important issues. 

While some panelists, including Kak 
and Schenker, gave high marks in regards 
to past accomplishments and shared Al¬ 
len’s optimism towards the future, Jain 
and Ganapathy expressed more reserva¬ 
tions about past accomplishments. They 
also conveyed skepticism toward the cur¬ 
rent state of research and sounded less op¬ 
timistic about the future. 

Kak and Schenker cited advances in 
mobile robots, 3D sensing, kinematic and 
dynamic control, and kinematic planning 
as evidence of success. Jain and Ganapa¬ 
thy viewed these successes as limited and 
said they see a trend emerging within the 
research community toward increasingly 
relying on simulations. They also criti¬ 
cized the lack of experimental verifica¬ 
tions in some of the studies published in 
today’s literature. Other panel members 
didn’t seem to share such a conviction on 
the current state of the field, but did not 
completely disagree with Jain and Gana¬ 
pathy, either. 

Regarding future directions, both Al¬ 
len and Kak believe we should continue 
building and experimenting with “com¬ 
plete” autonomous robotic systems to¬ 
ward an ultimate goal of achieving auton¬ 
omy. Both Ganapathy and Jain disagreed, 
but for different reasons. 

Ganapathy did not feel that complete 
autonomy should be the ultimate goal. He 
felt that some researchers share an unre¬ 
alistic expectation to build robots that are 
comparable to humans and pointed out 
that intelligent robots should augment 
humans and not replace them. 

Schenker seemed to agree and pre¬ 
dicted the need for teleoperated and 
semiautonomous systems. He also 
pointed out that we need to better under¬ 
stand adaptive control of planning and 
perception in the future, a belief each 
panelist shared. 

Jain questioned the rationale behind 
building complete systems when we still 
have an insufficient understanding of the 
individual components making up sys¬ 
tems. He suggested we spend more time 
experimenting and understanding low- 
level components so we can engineer bet¬ 
ter systems. 

In response to a question on real-time 
computing raised by a member of the au¬ 
dience, some of the panel members dis¬ 
agreed on the point — if any — at which 
such issues should be considered in de¬ 
signing intelligent robots. According to 
Kak, such issues should be left to a person 
who is more familiar with computer hard¬ 
ware and architecture issues. 

This view was not favorably received 
by some of the panelists. Allen pointed 


out that when designing robotic systems, 
he does not use any algorithm that re¬ 
quires computing on the order of minutes, 
suggesting that real-time issues should 
be considered at every phase of the devel¬ 
opment. 

Such lively discussions continued for 
two hours, with conversations ranging 
from edge detection to the degree of au¬ 
tonomy present in today’s systems and to 
whether tomorrow’s machines should be 
semiautonomous, teleoperated, or com¬ 
pletely autonomous. 

Direct questions such as “Is complete 
autonomy even possible?” were deliber¬ 
ately not answered during these discus¬ 
sions. No one expected concrete answers, 
merely a discussion of the present-day re¬ 
search and technology and what possi¬ 
bilities the future might hold in intelli¬ 
gent robotic systems. Another factor that 
led to the success of the session was the 
diverse nature of the panelists and the au¬ 
dience. 

Autonomous navigation session. 
Martin Herman of the National Institute 
of Standards and Technology chaired this 
session. David Payton of Hughes Re¬ 
search Laboratories led off by discussing 
a reactive, real-time control architecture 
for autonomous outdoor navigation of 
mobile robots. The autonomous land ve¬ 
hicle (ALV) system consists of two major 
modules: perception and planning. The 
system is designed to satisfy all funda¬ 
mental survival goals at the reactive 
level. High-level plans are expressed in a 
form that allows them to be used as advice 
and information to the reactive control 
levels so problems requiring opportunis¬ 
tic reaction to unexpected changes in the 
environment can be solved more easily. 

The ALV keeps contact with a radio 
tower; thus the path generated by the 
ALV’s planning module must avoid pos¬ 
sible RF shadows in the terrain. The plan¬ 
ning and perception systems that Hughes 
developed guided the ALV over a 600- 
meter cross-country course at a speed of 3 
kilometers per hour. Hughes is also run¬ 
ning experiments in a simulated environ¬ 
ment using simulated laser range data. 

Edward Riseman of the University of 
Massachusetts next described his work 
with Allen Hanson on autonomous navi¬ 
gation in a known environment as an inte¬ 
gration of three subsystems: planning, 
perception, and action. The navigation 
strategy relies on model-based vision. 
The robot detects several landmarks from 
an image and attempts to match these 
landmarks to a 3D model of the surround¬ 
ing terrain. The landmarks are usually ob¬ 
jects like buildings and telephone poles. 
The robot can then keep track of its posi¬ 
tion within the 3D model and plan its next 
move accordingly. 


Martial Hebert of Carnegie Mellon 
University addressed recent progress on 
the CMU Navlab, along with planetary 
exploration walking robots, work he did 
with Eric Krotkov, Takeo Kanade, and 
Charles Thorpe. Hebert considers robots 
to be physical, problem-solving systems, 
and he argues that robot design needs to 
consider task-specific models, the ex¬ 
plicitness of representations, and archi¬ 
tectural support. 

He illustrated the concept using two 
example systems. The first example came 
from Navlab. He made a comparison be¬ 
tween Codger and Eddie, the communi¬ 
cation and database systems. Codger was 
designed as a general system, but suffers 
from architectural overkill and difficult 
system maintenance, while Eddie, which 
replaced Codger, focuses on real issues 
of local vehicle navigation, high-speed 
lower level, and simplified, fast, point- 
to-point communications. In the second 
example, Hebert presented the design of a 
walking machine for planetary explora¬ 
tion on Mars and showed that in an envi¬ 
ronment that requires high performance 
in terms of processing speed, difficulty of 
scenes, and precision of output, special¬ 
ized perception and architectures are in¬ 
evitable and desirable. 

Information analysis session. Ter¬ 
rance Boult of Columbia University 
chaired the presentation on “Information 
Analysis: Languages, Models, and Algo¬ 
rithms.” 

Thomas Speeter of AT&T Bell Labs 
spoke first, describing a programming 
language for the description and control 
of dextrous manipulation of the Utah/ 
MIT dextrous hand. He said that the Hand 
Programming Language (HPL) was cre¬ 
ated to allow users to describe dextrous 
manipulation at a high level because of 
.the inherent complexity and depth of 
knowledge required to program the hand 
and the need for an abstraction of the ma¬ 
nipulation process to help in planning and 
describing long manipulation sequences. 

The abstraction used to describe ma¬ 
nipulation is based on motion primitives 
such as “open,” “close,” “pinch,” and 
“swing.” Speeter argues that the concept 
of motion primitives is borrowed from 
physiological motor control and that 
feedback is required for learning, error 
correction, and fine tuning. But, said 
Speeter, refinement and playback of mo¬ 
tor programs is clearly part of the physio¬ 
logical repertoire as well. 

The second speaker of the session, Jain 
of the University of Michigan, addressed 
issues on environment models and infor¬ 
mation assimilation. He proposed to use 
environment models (EMs) to represent 
the state of an autonomous intelligent 
agent that combines perception, cogni- 
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tion, and action. The EM is the heart of his 
system and is responsible for interaction 
among different components for provid¬ 
ing temporal coherence, combining in¬ 
formation from multiple sensors, and de¬ 
tailing the purposeful behavior of the sys¬ 
tem. Jain suggested that the combination 
of information from disparate sensors 
should be viewed as a problem in infor¬ 
mation assimilation rather than sensor in¬ 
tegration. He said the focus in informa¬ 
tion assimilation is on the physical world 
being modeled, that sensory information 
is just a means to the end, and that sensor 
integration treats the goal implicitly, 
misplacing the focus on the processing of 
sensed information. 

Next, Jean-Claude Latombe of Stan¬ 
ford University described the work he did 
with J. Barraquand and Bruno Langlois 
on numerical potential field techniques 
for robot path planning. The principle of 
their approach to the path planning prob¬ 
lem consists of a hierarchical, bit-map 
description of the objects, numerical 
computation of potential field over work¬ 
space without local minima, combination 
of workspace potentials, efficient sys¬ 
tematic techniques for escaping local 
minima, and incremental construction of 
graphs connecting different local min¬ 
ima. Langlois has stated that using 


multiscale pyramids of bit-map arrays to 
represent both the workspace and the 
configuration space of the robot allows 
efficient utilization of numerical poten¬ 
tial fields. He has shown that these tech¬ 
niques in path planning are very fast and 
capable of handling systems with many 
degrees of freedom. 

Intelligent robotic systems session. 
Latombe chaired this session, and Kak of 
Purdue University led off by discussing 
model-driven vision for object recogni¬ 
tion and mobile robot navigation. In the 
vision system for 3D object recognition 
(3D-Poly), feature data are organized for 
the models using a data structure called 
the feature sphere, and local feature sets 
are used for hypothesis generation. The 
combination of the two results in a system 
whose time complexity has a low-order 
polynomial bound. Kak also presented a 
model-driven, mobile robot navigation 
system (PSEIKI) using hierarchical evi¬ 
dence accumulation method. The 
Dempster-Shafer formalism is used for 
associating belief values with the differ¬ 
ent possible labels for the constructed ab¬ 
straction in the perceived image. 

Bir Bhanu of the Honeywell System 
and Research Center next presented de¬ 
tails of proposed intelligent systems for 


air and land vehicles. He discussed a re¬ 
search project on obstacle detection dur¬ 
ing helicopter low-altitude flight and 
landing. He stated that the results of the 
project could also be applied to autono¬ 
mous safe landing on Mars. For land ve¬ 
hicles, Bhanu also described ongoing re¬ 
search projects including dynamic scene 
understanding for motion detection, rec¬ 
ognition, tracking and terrain interpreta¬ 
tion, a human engineered remote driving 
system, and path planning and retrace 
navigation capabilities. 

Brian Schmult of AT&T Bell Labs, the 
final speaker of the day, described a 
working multirobot system for automatic 
disassembly of Lego structures. The sys¬ 
tem can disassemble complex Duplo 
structures from a simple object model. 
The emphasis is on a real system so as to 
locate and analyze the true nature of diffi¬ 
culties, as opposed to suspected prob¬ 
lems. Schmult reported work done on 
several significant problems associated 
with automatic robotic disassembly. 
These are planning, stability analysis, 
fragility analysis, multirobot coopera¬ 
tion, and path and grasp planning. He 
demonstrated his system with a video 
tape showing a sequence of dual-robot 
operations disassembling a complicated 
Lego structure. 
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CALL FOR PAPERS 


Conf. on Multiuser Interfaces and Applica¬ 
tions: Sept. 24-26, 1990, Heraklion, Crete, 
Greece. Sponsors: IFIP et al. Submit paper by 
Feb. 20, 1990, to Simon Gibbs, Centre Univer- 
sitaire d’Informatique, 12 rue du Lac, Ge-neva 
1207, Switzerland, phone 41 (22) 787-65-87. 

Vision 90: Nov. 12-15, 1990, Detroit. Cospon¬ 
sors: Society of Manufacturing Engineers and 
SME Machine Vision Assoc. Submit abstract 
by Feb. 23,1990, to Vision 90, SME Conf. 
Dept., PO Box 930, Dearborn, MI, phone (313) 
271-1500. 


EKAW 90, Fourth European Knowledge 
Acquisition for Knowledge-Based Systems 
Workshop: June 25-29, 1990, Amsterdam. 
Submit paper by Feb. 26,1990, to Bob Wielin- 
ga, Social Science Informatics, Univ. of Am¬ 
sterdam, Herengracht 196, 1016 BS Amster¬ 
dam, Netherlands, phone 31 (20) 525-2160. 

Proc. of the IEEE plans a special issue in Janu¬ 
ary 1991 on ISDN. Submit paper on networks, 
service, systems, performance, switching, 
standardization efforts, device developments, 
future trends, and new directions by Feb. 28, 
1990, to W.W. Wu, Intelsat, 3400 International 
Dr. NW, Washington, DC 20008-3098, phone 
(202) 944-7224. 


First Japanese Knowledge Acquisition for 
Knowledge-Based Systems Workshop: Oct. 
25-26, 1990, Kyoto, Japan, and Oct. 29-31, 
1990, Tokyo. Cosponsors: Kansai Inst, of In¬ 
formation Systems et al. Submit draft by Feb. 
28,1990, to Hiroshi Motoda, Advanced Re¬ 
search Lab, Hitachi, Kokubunji, Tokyo 185, 


OOPSLA 90, Fifth Conf. on Object- 
Oriented Programming Systems, Lan¬ 
guages, and Applications: Oct. 21-25, 1990, 
Ottawa, Canada. Cosponsor: ACM. Submit 
paper by Mar. 1, 1900, to Akinori Yonezawa, 
Information Science Dept., Faculty of Sci¬ 
ence, Univ. of Tokyo, 7-3-1, Hongo, Bunkyo- 
ku, Tokyo, 113 Japan. 


1990 Conf. on Software Maintenance: 

Nov. 26-29, 1990, San Diego, Calif. Sub¬ 
mit paper by Mar. 1,1990, to John Munson, 
Computer Science Div., Univ. of West Florida, 
Pensacola, FL 32514, phone (904) 474-2989; 
or Malcolm Munro, Centre for Software Main¬ 
tenance, Univ. of Durham, Durham DH1, 3LE, 
England, phone 44 (091) 374-2634. 


DIAC 90, Directions and Implications of 
Advanced Computing: July 28, 1990, Bos¬ 
ton. Sponsor: Computer Professionals for So¬ 
cial Responsibility. Submit abstract and paper 
by Mar. 1, 1990, to Douglas Schuler, Boeing 
Computer Services, MS 7L-64, PO 24346, Se¬ 
attle, WA 98124-0346, phone (206) 865-3226. 


ICCS 90, Int’l Conf. on Communication Sys¬ 
tems: Nov. 5-9, 1990, Singapore. Cosponsors: 
IEEE Singapore Section et al. Submit abstract 
by Mar. 1,1990, to T.T. Tjhung, ICCS 90, c/o 
Meeting Planners Pte. Ltd., 100 Beach Rd. 
#33-01, Shaw Towers, Singapore 0718. 

Second Int’l Workshop on Advances in Ro¬ 
bot Kinematics: Sept. 10-12, 1990, Linz, Aus¬ 
tria. Sponsors: Research Inst, for Symbolic 
Computation et al. Submit paper by Mar. 1, 
1990, to Sabine Stifler, RISC, Johannes Kepler 
Univ., A-4040 Linz, Austria, phone 43 (7236) 
3231-50; or Jadran Lenarcic, Josef Stefan 
Inst., Univ. of Edvard Kardelj, Jamova 39, 
61111 Ljubljana, Yugoslavia, phone 38 (61) 
214-399. 

IAPR Workshop on Syntactic and Struc¬ 
tural Pattern Recognition: June 13-15, 1990, 
Murray Hill, N.J. Sponsor: Int’l Assoc, for Pat¬ 
tern Recognition. Submit abstract by Mar. 1, 
1990, to Henry S. Baird, AT&T Bell Laborato¬ 
ries, Rm. 2C-557, 600 Mountain Ave., Murray 
Hill, NJ 07974, phone (201) 582-5744. 

Second lnt’1 Conf. on Microelectronics: 

Oct. 13-15, 1990, Damascus, Syria. Sponsor: 
Arab School of Science and Technology. 
Submit paper by Mar. 1,1990, to M.I. Elmasry, 
VLSI Research Group, Univ. of Waterloo, 
Waterloo, Ont., Canada N2L 3G1 (for authors 
in North America and Europe); or A. Arman- 
azi, Electronics Inst, for Scientific Studies, 

PO Box 4470, Damascus, Syria (all other au¬ 
thors). 


14th SCAMC, 1990 Symp. on Comput- 
er Applications in Medical Care: Nov. 
4-7, 1990, Washington, DC. Cosponsors: 
George Washington Univ. Medical Center et 
al. Submit draft manuscript by Mar. 1, 1990, to 
Randolph A. Miller, M.D., 1990 SCAMC, Sec¬ 
tion of Medical Informatics, Dept, of Medi¬ 
cine, Univ. of Pittsburgh School of Medicine, 
B50A Lothrop Hall, 190 Lothrop St., Pitts¬ 
burgh, PA 15261. 

IEEE Trans, on Knowledge and Data 
Engineering plans a special section on 
enabling technology for knowledge-based 
systems. Submit paper by Mar. 2,1990, to 
Howard E. Shrobe, Symbolics, Inc., 8 New 
England Executive Park East, Burlington, MA 
01803, phone (617) 221-1304; or Se June 
Hong, IBM T.J. Watson Research Center, PO 
Box 218, Yorktown Heights, NY 10598, phone 
(914) 945-2265. 


SIGComm 90 Conf.: Aug. 1-5, 1990, Phila¬ 
delphia. Sponsor: ACM SIGComm. Submit 
paper by Mar. 2,1990, to Phil Kam, Bell Com¬ 
munications Research, MS 2P-357, 445 South 
St., PO Box 1910, Morristown, NJ 07962- 
1910, phone (201) 829-4299. 


i^j^! Frontiers 90, Third Symp. on Fron- 
'^*7 tiers of Massively Parallel Computa¬ 
tion: Oct. 8-10, 1990, College Park, Md. Co¬ 
sponsor: NASA Goddard Space Flight Center. 
Submit extended abstract by Mar. 15, 1990, to 
Joseph JaJa, Frontiers 90, UMIACS, Univ. of 
Maryland, A.V. Williams Bldg., College Park, 
MD 20742, phone (301) 454-1808. 


ACM Trans. Information Systems plans a spe¬ 
cial issue on user interface software. Submit 
paper by Mar. 15,1990, to Brad A. Myers, 
School of Computer Science, Carnegie Mellon 
Univ., Pittsburgh, PA 15213-3890, phone 
(412) 268-5150. 


Int’l J. Computer-Aided VLSI Design plans a 
special issue on heuristic algorithms. Sponsor: 
Ablex Publishing. Submit paper by Mar. 15, 
1990, to Bozena Kaminska, Electrical Engi¬ 
neering Dept., Ecole Polytechnique de Mon¬ 
treal, PO Box 6079, Station A, Montreal, Que., 
Canada H3C 3A7. 


Future Trends 90, Workshop on Fu- 
’5P' ture Trends of Distributed Computing 

Systems: Sept. 30-Oct. 2, 1990, Cairo. Submit 
paper by March 16,1990, to Stephen S. Yau, 
Univ. of Florida, CIS Dept., Rm. 301, Gaines¬ 
ville, FL 32611, phone (904) 335-8006. 


10th Inf’ Conf. in Computer Science: July 
23-27, 1990, Santiago, Chile. Submit extended 
abstract by Mar. 20,1990, to Joachim von zur 
Gathen, Computer Science Dept., Univ. of 
Toronto, 10 King’s College Rd., Toronto, Can¬ 
ada M5S 1A4, phone (416) 978-6024. 


ICCC 90,10th Int’l Conf. on Computer 
Communication: Nov. 5-9, 1990, New Delhi, 
India. Sponsor: Int’l Council on Computer 
Communication. Submit paper by Mar. 20, 
1990, to Saroj Chowla, ICCC 90 Secretariat, 
CMC Ltd., A-5 Ring Rd., South Extension Part 
I, New Delhi 110 049, India, phone 91 (11) 626- 
807. 


1990 Int’l Electronics Packaging Conf.: 

Sept. 9-13, 1990, Marlborough, Mass. Spon¬ 
sor: Inf 1 Electronics Packaging Society. Sub¬ 
mit abstract by Mar. 30,1990, to IEPS 1990 
Program Committee, 114 N. Hale St., Whea¬ 
ton, IL 60187, phone (708) 260-1044. 

Int’l J. Intelligent Systems plans a special vol¬ 
ume on knowledge acquisition. Submit paper 
by Mar. 30,1990, to Kenneth M. Ford, Inst, for 
Human and Machine Cognition, Computer 
Science Div., Univ. of West Florida, Pensa¬ 
cola, FL 32514, phone (904) 474-2551. 

J. Internetworking: Research and Experi¬ 
ence seeks original research papers for its sec¬ 
ond issue. Submit full paper or short technical 
note by Mar. 31,1990, to Deborah L. Estrin, 
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Computer Science Dept., Univ. of Southern 
California, Los Angeles, CA 90089-0782, 
phone (213) 743-7842. 


AAECC 8, Eighth Int’l Conf. on Applied Al¬ 
gebra, Algebraic Algorithms, and Error- 
Correcting Codes: Aug. 20-24, 1990, Tokyo. 
Submit paper by Mar. 31,1990, to Hideki 
Imai, Faculty of Engineering, Yokohama Na¬ 
tional Univ., Tokiwadai, Hodogaya-ku, 
Yokohama 240, Japan. 


1^3^, IEEE Expert is planning a series of ar- 
tides on object-oriented programming 
in artificial intelligence. Submit full manu¬ 
script by Apr. 1, 1990, to Sherman Alpert, PO 
Box 704, Yorktown Heights, NY 10598, phone 
(914) 789-7736. 


Int’l Symp. on Fuzzy Approach to Rea- 
V57 soning and Decision Making: June 25- 
29, 1990, Bechyne, Czechoslovakia. Cospon¬ 
sor: Int’l Fuzzy System Assoc. Submit paper 
by Apr. 1,1990, to Milan Mares, UTIA- 
CSAV, Pod Vodarenskou Vezi 4, 182 08 Praha 
8, Czechoslovakia. 


■£2^, IEEE Conf. on Managing Expert Sys- 
*5»7 tern Programs and Projects: Sept. 10- 
12, 1990, Washington, DC. Sponsor: IEEE 
Computer Society Task Force on Expert Sys¬ 
tems. Submit paper by Apr. 1,1990, to Randall 
Shumaker, Navy Center for Applied Research 
in AI, Code 5510, Naval Research Lab, Wash¬ 
ington, DC 20375. 

Ninth Symp. on Reliable Distributed 

Systems: Oct. 9-11, 1990, Huntsville, 
Ala. Submit paper by Apr. 1,1990, to Geneva 
Belford, Univ. of Illinois, 1304 W. Springfield 
Ave., Urbana, IL 61801, phone (217) 333- 


£2^ Fifth Rocky Mountain Conf. on Artifi- 
*5*7 cial Intelligence: June 28-30, 1990, Las 
Cruces, N.M. Cosponsors: ACM et al. Submit 
paper by Apr. 1,1990, to Paul McKevitt, Com¬ 
puting Research Lab, Dept. 3CRL, Box 30001, 
New Mexico State Univ., Las Cruces, NM 
88003-0001, phone (505) 646-5109. 


Internal Audit Advanced Technology Fo¬ 
rum: Sept. 17-19, 1990, Orlando, Fla. Spon¬ 
sor: Inst, of Internal Auditors. Submit paper by 
Apr. 1, 1990, to Frank Allen, IIA, 249 Mait¬ 
land Ave., Altamonte Springs, FL 32701- 
4201. 

Fourth Conf. on Putting Methods and Tools 
into Practice as Aids to Design Information 

Systems: September 25-27, 1990, Nantes, 
France. Sponsor: Univ. de Nantes, Inst. Univ. 
de Technologie, Lab. dTnformatique, Liana. 
Submit paper by Apr. 1,1990, to H. Habrias, 3 
Rue du Marechal Joffre, 44041 Nantes Cedex 
01, France, phone (33) 4030-6090. 


1990 IEEE Workshop on Visual Languages: 

Oct. 4-6, 1990, Skokie, Ill. Cosponsors: Univ. 
of Pittsburgh et al. Submit abstract and paper 
by Apr. 1, 1990, to S.K. Chang, Computer Sci¬ 
ence Dept., Univ. of Pittsburgh, Pittsburgh, PA 
15260. 


Iecon 90,16th Conf. of the IEEE Industrial 
Electronics Society: Nov. 27-30, 1990, Pa¬ 


cific Grove, Calif. Submit abstract and sum¬ 
mary by Apr. 1,1990, to Alfred C. Weaver, 
Computer Science Dept., Thornton Hall, Univ. 
of Virginia, Charlottesville, VA 22903, phone 
(804) 982-2201 (for authors in North and South 
America); Adolf Habock, Siemens AG, Strom- 
richterwerk Erlangen, Frauenauracher Str. 80, 
D-8520 Erlangen, West Germany, phone 49 
(9131) 731-312 (for Europe); or Hiromasa 
Haneda, Electronics Engineering Dept., Kobe 
Univ., Rokko-dai, Nada-ku, Kobe City, Hyogo 
675, Japan, phone 81 (78) 881-1212 (for other 
regions). 

Fourth Southeastern Small-College 
Computing Conf.: Nov. 9-10, 1990, Hick¬ 
ory, N.C. Sponsor: Consortium for Computing 
in Small Colleges. Submit extended abstract 
by Apr. 1,1990, to Susan Dean, Samford 
Univ., 800 Lakeshore Dr, Birmingham, AL 
35229. 

Int’l Workshop on Expert Systems in Engi¬ 
neering: Sept. 24-26, 1990, Vienna, Austria. 
Sponsor: Christian Doppler Expert Systems 
Lab, Univ. of Vienna. Submit paper by Apr. 1, 
1990, to Wolfgang Nejdl, Technical Univ. of 
Vienna, Applied Computer Science Dept., CD 
Lab for Expert Systems, Paniglgasse 16, 1040 
Vienna, Austria. 

ICDT 90, Third Int’l Conf. on Database The¬ 
ory: Dec. 11-15, 1990, Paris. Sponsor: INRIA. 
Submit extended abstract by Apr. 2, 1990, to 
Paris Kanellakis, ICDT 90, Brown Univ., 
Computer Science Dept., PO Box 1910, Provi¬ 
dence, RI 02912, phone (401) 863-7647; or 
INRIA, Domaine de Voluceau — Rocquen- 
court, BP 105, 78153 Le Chesnay Cedex, 
France; phone 33 (l)-3963-5500. 


CASE 90, Fourth Int’l Workshop on 
Computer-Aided Software Engineer¬ 
ing: Dec. 5-8, 1990, Irvine, Calif. Cosponsors: 
British Computer Society et al. Submit posi¬ 
tion paper by Apr. 30, 1990, to Wayne Stevens, 
IBM, 472 Wheelers Farms Rd„ Milford, CT 
06460-2757, phone (203) 783-4432. 


J. Intelligent Manufacturing plans a special 
issue in January 1991 on research in languages, 
frameworks, and databases. Submit paper by 
Apr. 30, 1990, to Evangelos Simoudis, AI Ap¬ 
plications Group, DEC, 290 Donald Lynch 
Blvd., MS DLB5-2/B4, Marlboro, MA 01752. 


2nd IEEE Symp. on Parallel and Dis- 
^§7 tributed Processing: Dec. 10-12, 1990, 
Dallas. Sponsor: Dallas Section, IEEE Com¬ 
puter Society. Submit paper by May 1,1990, to 
Behrooz Shirazi, Computer Science and Engi¬ 
neering Dept., Southern Methodist Univ., Dal¬ 
las, TX 75275, phone (214) 692-2874. 


11th Real-Time Systems Symp.: Dec. 
'5§7 5-7, 1990, Orlando, Fla. Submit paper by 
May 1,1990, to Jane W.S. Liu, 1304 W. 
Springfield Ave., Computer Science Dept., 
Univ. of Illinois, Urbana, IL 61801-3082, 
phone (217) 333-0135. 


AIRIES 90, AI Research in the Environ¬ 
mental Sciences Workshop: Sept. 25-27, 
1990, Montreal, Que., Canada. Cosponsors: 
Univ. of Quebec at Montreal, Centre Re- 
searche Informatique de Montreal. Submit ab¬ 
stract for oral presentation, poster presenta¬ 
tion, or demonstration by May 1, 1990, to 
Rosemary M. Dyer, GL/LYP, AIRIES 90, Air 
Force Geophysics Lab, Hanscom Air Force 
Base, MA 01731. 


Supercomputing 90: Nov. 12-16, 1990, 
New York City. Cosponsor: ACM. Sub¬ 
mit paper by Apr. 15,1990, to Daniel V. Pryor, 
Supercomputing Research Center, 17100 Sci¬ 
ence Dr., Bowie, MD 20715, phone (301) 805- 
7407. 


ACM SIGSoft 90, Fourth Symp. on Software 
Development Environments: Dec. 3-5, 1990, 
Irvine, Calif. Submit paper by Apr. 16, 1990, to 
Richard N. Taylor, Information and Computer 
Science Dept., Computer Science Bldg., Rm. 
444, Parking Lot 18, Univ. of California, Ir¬ 
vine, CA 92717. 

14th Western Educational Computing 

Conf.: Nov. 15-16, 1990, Irvine, Calif. Spon¬ 
sor: California Educational Computing Con¬ 
sortium. Submit paper by Apr. 21,1990, to 
Oliver Seely, Jr., California State Univ. at 
Dominguez Hills, Chemistry, 1000 E. Victoria 
St., Carson, CA 90747. 


Second Int’l Conf. on Algebraic and Logic 
Programming: Oct. 1-3, 1990, Nancy, 
France. Submit paper by Apr. 27, 1990, to 
Wolfgang Wechler, TU Braunschweig, Theo- 
retische Informatik, Postfash 3329, D-3300 
Braunschweig, West Germany. 


ICCV 90, Third Int’l Conf. on Com- 
*5*7 puter Vision: Dec. 4-7, 1990, Osaka, Ja¬ 
pan. Submit paper by Apr. 30, 1990, Saburo 
Tsuji, Osaka Univ., Control Engineering 
Dept., Toyonaka, Osaka 560, Japan. 


<£3^1 TAI 90, Second Computer Society 
5*7 Int’l Conf. on Tools for Artificial Intel¬ 
ligence: Nov. 6-9, 1990, Washington, DC. Co¬ 
sponsors: Rutgers Univ. et al. Submit panel 
proposal, tutorial proposal, and full paper by 
May 15, 1990, to W.T. Tsai, Computer Science 
Dept., 4-192 EE/CS Bldg., 200 Union St. SE, 
Univ. of Minnesota, Minneapolis, MN 55455, 
phone (612) 625-6371. 

15th Conf. on Local Computer Net- 
*557 working: Oct. 1-3, 1990, Minneapolis, 
Minn. Submit paper by May 22, 1990, to Marc 
Cohn, Advanced Development Div., Raychem 
Corp., 300 Constitution Dr., Menlo Park, CA 
94025-1164, phone (415) 361-3902. 

Micro 23, 23rd Symp. and Workshop 
'C*y on Microprogramming and Micro¬ 
architecture, Nov. 27-29, 1990, Orlando, Fla. 
Cosponsor: ACM. Submit full paper by June 
15, 1990, to Chris Papachristou, Case Western 
Reserve Univ., Computer Engineering and 
Science Dept., Cleveland, OH 44106, phone 
(216) 368-5277; or Vicki Allan, Utah State 
Univ., Computer Science Dept., Logan, UT 
84321-4205, phone (801) 750-2022. 


IAPR Workshop on Machine Vision Appli¬ 
cations: Nov. 28-30, 1990, Tokyo. Sponsor: 
International Assoc, for Pattern Recognition. 
Submit summary by June 30, 1990, to Mikio 
Takagi, Inst, of Industrial Science, Univ. of 
Tokyo, 7-22-1 Roppongi, Minatoku, Tokyo 
106, Japan, phone 81 (3) 479-0289. 
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CALL FOR PAPERS 


IEEE Conference on 

Managing Expert System September 10-12,1990 

Programs and Projects Washington, dc 


Sponsored by: IEEE Computer Society Technical Committee on Expert Systems (Chair, Harry Siegel) 


IEEE COMPUTER SOCIETY 


T he Managing Expert Systems Programs and Projects 
conference is dedicated to the development of expert 
systems from the management perspective. All topics 
related to management issues are suitable to be addressed in 
this forum. The conference offers a wide ranging program of 
paper and panel sessions, tutorials and workshops. 

Paper Submission Requirements 

Authors should submit full papers to the Program Chairman not 
later than April 1,1990. Each submission must include one cover 
page and five copies of the complete manuscript. 

The cover page should include: 

• Name(s), affiliation(s), complete address(es), telephone and 
E-Mail for the principal author, and the title of the paper. 

The five copies of the manuscript should each include: 

• Title and Abstract Page 

• The complete English language text, not to exceed 10 pages, 
including illustrations. 

Notice of acceptance will be sent by May 15 to the principal 
authors. 

Keynote Addresses: 

• Ed Mahler, Dupont 

“Managing Expert System Programs” 

• David Bendel Hertz, University of Miami 
“Expert Systems and Neural Networks” 

• Michael Gemignani, University of Houston-Clear Lake 
“Potential Liability of Expert Systems” 



Expert System Topics of Interest 

• Cost Justification 

• Institutionalization 

• Political Socialization 

• Maintenance 

• Measuring Expert System Productivity 

• Legal Issues of Expert Systems Use 

• Project Management Techniques 

• Verification, Validation, and Testing 

• Development from the Expert’s Perspective 

• Staffing 

• Building an Expert System Capability 

• PC/Workstation.'Mainframe-based Systems 

• Integrating Expert Systems with Conventional Data 
Processing 

• Embedding Expert Systems 

• Financing Your Expert System Projects 

• Managing the Knowledge Acquisition Process 

• Future Trends in Expert Systems 

• Lessons Learned-Development and Management 

• Specifications of Expert Systems 


CONFERENCE CHAIR CONFERENCE VICE CHAIR 

Dr. Jay Liebowitz Jerry Feinstein 

George Washington University Triton/Phase Linear Systems, Inc. 


PROGRAM CHAIR 

Dr. Randall Shumaker 

Navy Center for Applied Research in A1 
Code 5510 

Naval Research Laboratory 

Washington, D.C. 20375 

PANEL CHAIR 

Major Denis Rochette 

HQ DA, OCSA 

Attn: CSDS-AI, Pentagon Room 1D659 
Washington, D.C. 20310 
(202) 694-6900 

TUTORIALS CHAIR 

Dr. Deborah A. Finley 

Interactive Communications, Inc. 

8226 Fenton Street, Suite 202 

Silver Spring, MD 20910 
(301)588-0003 


CONFERENCE COMMITTEE 


Dr. Randall Shumaker-Program Chair 
Naval Research Laboratory 

Major Denis Rochette-Panels Chair 

US Army 

Dan Yurman 

EG&G Idaho. Inc. 

Dr. Deborah A. Finley-Tutorials Chair 
Interactive Communications, Inc. 

R. Glenn Wright-Publicity Chair 

Prospective Computer Analysts, Inc. 

Dr. Rick Steinheiser 

John Segna-Finance Chair 

Environmental Resources Management. Inc. 

Les Lancaster-Exhibits Chair 

Nuclear Regulatory Commission 

Janet S. Zeide, Esq.-Local Arrangements Chair 












CALENDAR 


February 1990 


1990 Workshop on VLSI, Feb. 18-21, 

Clearwater Beach, Fla. Contact Sami Al- 
Arian, Computer Science and Engineering 
Dept., Univ. of South Florida, Tampa, FL 
33620, phone (813) 974-3544. 


CSC 90, 18th Computer Science Conf., Feb. 
19-22, Washington, DC. Sponsor: ACM. Con¬ 
tact Barbara Kyriakakis, Computer Science 
Dept., George Mason Univ., Fairfax, VA 
22030, phone (703) 323-2318. 


21st SIGCSE Technical Symp. on Computer 
Science Education, Feb. 22-23, Washington, 
DC. Sponsor: ACM Special Interest Group on 
Computer Science Education. Contact Rich¬ 
ard Austing, Computer Science Dept., Univ. of 
Maryland, College Park, MD 20742, phone 
(301) 454-2002. 


Nepcon West 90, Nat’l Electronic Packaging 
and Production Conf., Feb. 26-Mar. 1, 

Anaheim, Calif. Contact Michael Critser, 
Nepcon Conf. Group, 1350 E. Touhy Ave., Des 
Plaines, IL 60017-5060, phone (312) 299- 
9311. 


Compcon Spring 90, Feb. 26-Mar. 2, 

San Francisco. Contact Kenichi Miura, 
Computational Research Dept., MS B2-7, 
Fujitsu America, 3055 Orchard Dr., San Jose, 
CA 95134-2017, phone (408) 432-1300, ext. 
5723; or Compcon Spring 90, IEEE Computer 
Society, 1730 Massachusetts Ave. NW, Wash¬ 
ington, DC 20036-1903, phone (202) 371- 
1013. 


(gfji Third Int’l Software for Strategic Sys- 
terns Conf., Feb. 27-28, Huntsville, Ala. 
Cosponsors: IEEE Computer Society Hunts¬ 
ville Chapter et al. Contact Continuing Educa¬ 
tion Div., Univ. of Alabama in Huntsville, Tom 
Bevill Center 285, Huntsville, AL 35899, 
phone (800) 448-4035 or (205) 895-6372. 


March 1990 


Eighth Nat’l Conf. on Ada Technology, Mar. 
5-8, Atlanta. Contact Eighth Nat’l Conf. of Ada 
Technology, US Army Communications— 
Electronics Command, Attn.: AMSEL-RD- 
SE-CRM (Kay Trezza), Fort Monmouth, NY 
07703-5000. 


A CAIA 90, Sixth IEEE Conf. on Artifi- 
' cial Intelligence Applications, Mar. 5- 


In the accompanying Calendar, the IEEE Computer Society logo indicates 
the conferences the society is sponsoring and participating in. Other confer¬ 
ences of interest to our readers, as well as their sponsors, are also listed. 

For inclusion in Call for Papers or Calendar, submit information at least six 
weeks before the month of publication (i.e., for the April 1990 issue, send infor¬ 
mation for receipt by February 15, 1990) to Chuck Governale, Calendar Dept., 
Computer, PO Box 3014, Los Alamitos, CA 90720-1264. 


9, Santa Barbara, Calif. Contact Se June Hong, 
IBM T.J. Watson Research Center, Rm. 31- 
206, PO Box 218, Yorktown Heights, NY 
10598, phone (914) 945-2265. 

Int’l Conf. on Neural Networks, Mar. 6-8, 

Lyon, France. Sponsors: Associazione Italiana 
per l’lnformatica ed II Calcolo Automatico et 
al. Contact Solange Dubeauclard, 1030 N. 
Glenhurst, Birmingham, MI 48009, phone 
(313) 647-7833. 

Second Symp. on Integrated Ferroelectrics, 
Mar. 6-8, Monterey, Calif. Contact Alona S. 
Miller, Microelectronics Research Labs, 

Univ. of Colorado at Colorado Springs, PO 
Box 7150, Colorado Springs, CO 80933-7150, 
phone (719) 593-3488. 


1990 Symp. on Advances in Semiconductors 
and Superconductors, Mar. 17-21, San Di¬ 
ego, Calif. Sponsor: SPIE. Contact Society of 
Photo-Optical Instrumentation Engineers, PO 
Box 10, Bellingham, WA 98227-0010, phone 
(206) 676-3290. 

Second Oregon Workshop on Software Met¬ 
rics, Mar. 19-20, Portland, Ore. Sponsors: 
Portland State Univ. et al. Contact Warren Har¬ 
rison, Computer Science Dept., Portland State 
Univ., PO Box 751, Portland, OR 97207-0751, 
phone (503) 464-3108. 

NCGA 90, Mar. 19-22, Anaheim, Calif. Con¬ 
tact National Computer Graphics Assoc., 2722 
Merrilee Dr., Suite 200, Fairfax, VA 22031, 
phone (703) 698-9600. 


Parbase 90, Int’l Conf. on Databases, Paral¬ 
lel Architectures, and Their Applications, 
Mar. 6-9, Miami Beach. Sponsors: Florida 
Int’l Univ. et al. Contact Parbase 90, School of 
Computer Science, Florida Int’l Univ., Miami, 
FL 33199, phone (305) 554-3429 or 3386. 


EDAC 90, European Design Automa¬ 
ta? tion Conf., Mar. 12-15, Glasgow, Scot¬ 
land. Contact Gordon Adshead, CEP Consul¬ 
tants, 26-28 Albany St., Edinburgh, EH1 3QH, 
Scotland, UK, phone 44 (31) 557-2478. 

ICCL 90,1990 Int’l Conf. on Com¬ 
te? puter Languages, Mar. 12-16, New 
Orleans. Contact Boumediene Belkhouche, 
Computer Science Dept., Tulane Univ., PO 
Box 5079, 301 Stanley Thomas Hall, New Or¬ 
leans, LA 70118, phone (504) 865-5840. 


Third Computer Virus Clinic, Mar. 14-15, 

New York City. Sponsor: Data Processing 
Management Assoc. Contact National Conf. 
Coordinator, DPMA, Box 894, New York, NY 
10268, phone (800) 835-2246, est. 190. 

Second Symp. on Principles and Practice of 
Parallel Programming, Mar. 14-16, Seattle. 
Sponsor: ACM SIGPlan. Contact Edward La- 
zowska, Computer Science Dept., Univ. of 
Washington, Seattle, WA 98195, phone (206) 
543-4755. 


UK IT (Information Technology) 1990 
Conf., Mar. 19-22, Southampton, UK. Spon¬ 
sors: IEE et al. Contact Conf. Services, Institu¬ 
tion of Electrical Engineers, Savoy PL, London 
WC2R 0BL, UK, phone 44 (1) 240-1871. 

Southcon 90, Mar. 20-22, Orlando, Fla. Spon¬ 
sors: IEEE Florida Council et al. Contact 
Southcon 90, 8110 Airport Blvd., Los Angeles, 
CA 90045. 


Eighth Built-In Self-Test Workshop, 
tS? Mar. 21-23, Charleston, S.C. Sponsors: 
IEEE Test Technology Committee. Contact 
Richard Sedmak, Self-Test Services, 6 Lin- 
denwold Terr., Ambler, PA 19002, phone 
(215) 628-9700. 


IPCCC, Ninth IEEE Int’l Phoenix Conf. on 
Computers and Communications, Mar. 21- 

24, Scottsdale, Ariz. Cosponsor: IEEE Com¬ 
munications Society. Contact Forouzan Gol- 
shani, Computer Science Dept., Arizona State 
Univ., Tempe, AZ 85287, phone (602) 965- 
2855. 


Hannover Fair Cebit 90, Mar. 21-28, Han¬ 
nover, West Germany. Contact Hannover Fairs 
USA, 103 Carnegie Center, Princeton, NJ 
08540, phone (609) 987-1202; or Gerrnan- 
Arab Chamber of Commerce, 3, Abu El Feda 
Bldg., Cairo-Zamalek, PO Box 385, Egypt, 
phone 20 (02) 3-41-36-62. 
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1990 Symp. on Interactive 3D Graph- 
ics, Mar. 25-28, Snowbird, Utah. Spon¬ 
sors: US Office of Naval Research et al. Con¬ 
tact Richard Riesenfeld, Univ. of Utah, Com¬ 
puter Science Dept., 3190 Merrill Engineering 
Bldg., Salt Lake City, Utah 84112, phone (801) 
581-8224. 

Conf. on AI, Simulation, and Planning 
in High-Autonomy Systems, Mar. 26- 

27, Tucson, Ariz. Cosponsors: Univ. of Ari¬ 
zona et al. Contact Bernard Zeigler, Electrical 
and Computer Engineering Dept., Office of 
Engineering Professional Development, Univ. 
of Arizona, Box 9 Harvill Bldg., Tucson, AZ 
85721, phone (602) 621-3054 or (602) 743- 
9551. 

1CSE 12, 12th Int’l Conf. on Software 
^57 Engineering, Mar. 26-30, Nice, France. 
Cosponsors: ACM, AFCET. Contact Francois- 
Regis Valette, CERT/DERI, PO Box 4026-2, 
Ave. Edouard Belin-31055 Toulouse, France, 
phone (33) 61-55-71-11; ICSE 12, AFCET, 

156 Bd. Pereire, 75017 Paris, France; or IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 

1990 Int’l Conf. on Extending Data- 
base Technology, Mar. 26-30, Venice, 
Italy. Cosponsors; EDBT Foundation et al. 
Contact Michael L. Brodie, Intelligent Data¬ 
base Systems Dept., GTE Labs, 40 Sylvan Rd., 
MS 62, Waltham, MA 02254, phone (617) 466- 
2256. 


1990 AAAI Spring Symp. on the Theory and 
Application of Minimal-Length Encoding, 
Mar. 27-29, Stanford, Calif. Contact Edwin 
Pednault, AT&T Bell Laboratories, Rm. 4F- 
611, Crawfords Comer Rd., Holmdel, NJ 
07733, phone (201) 949-1074. 

Supercomputing Japan 90, Mar. 27-29, To¬ 
kyo. Cosponsors: US Commerce Dept, et al. 
Contact Meridian Pacific Group, 116 E. 
Blithedale Ave., Suite 2, Mill Valley, CA 
94941, phone (415) 381-2255. 

Mathematical Sciences Inst. Symp., Mar. 
29-31, Ithaca, NY. Contact Diana Drake, MSI, 
Cornell Univ., 201 Caldwell Hall, Ithaca, NY 
14853-2602, phone (607) 255-7740. 

PDC 90, Conf. on Participatory Design of 
Computer-Based Applications, Mar. 31- 
Apr. 1, Seattle. Sponsors: Computer Profes¬ 
sionals for Social Responsibility, Computers 
in the Workplace Working Group. Contact Jeff 
Johnson, HP Labs, PO Box 10490, Palo Alto, 
CA 94303-0969, phone (415) 857-7661. 


April 1990 


Sixth MIT Conf. on Advanced Research in 
VLSI, Apr. 2-4, Cambridge, Mass. Contact 
Microsystems Research Center, Rm. 39-321, 
MIT, Cambridge, MA 02139, phone (617) 253- 
8138. 

19th Int’l Programmable Controller/Ex¬ 
pert Systems Conf., Apr. 3-5, Detroit. Spon¬ 
sor: Engineering Society of Detroit. Contact 
ESD, 100 Farnsworth, Detroit, MI 48202, 
phone (313) 832-5400. 

Hydrosoft 90, Int’l Conf. on Hydraulic Engi¬ 
neering Software, Apr. 3-5, Boston. Sponsor: 
Computational Mechanics Inst. Contact Liz 
Newman, CMI, Ashurst Lodge, Ashurst, 
Southampton, S04, 2AA, England, phone 042 
(129) 3223. 


Flairs 90, Florida AI Research Symp., Apr. 
3-6, Cocoa Beach, Fla. Contact Avelino J. 
Gonzalez, Computer Engineering Dept., Univ. 
of Central Florida, Orlando, FL 32816, phone 
(407) 281-5027. 


Fourth Parallel Processing Symp., 
v87 Apr. 4-6, Fullerton, Calif. Sponsor: 
IEEE Computer Society Orange County Chap¬ 
ter. Contact Larry H. Canter, c/o Computer 
Systems Approach, 1140 S. Raymond Ave., 
Suite B., Fullerton, CA 92631, phone (714) 
738-3414. 


VHDL Users’ Group Spring Meeting, 
^■7 Apr. 4-6, Boston. Contact Frederick 
Hinchliffe, CLSI, Suite 210, 15245 Shady 
Grove Rd., Rockville, MD 20850, phone (301) 
963-5200. 


1990 Symp. on Applied Computing, 
v!7 Apr. 5-6, Fayetteville, Ark. Cosponsors: 
Univ. of Arkansas, UA Student ACM Chapter. 
Contact Hal Berghel, Univ. of Arkansas, Com¬ 
puter Science Dept., Fayetteville, AR 72701, 
phone (501) 575-7343. 

OC 90, Int’i Topical Meeting on Opti- 
cal Computing, Apr. 8-12, Kobe, Japan. 
Cosponsors: SPIE et al. Contact S. Ishihara, 
Business Center for Academic Societies Ja¬ 
pan, 3-23-1, Hongo, Bunkyo-ku, Tokyo 113, 
Japan, phone 81 (3) 817-5831. 

1990 IEEE VLSI Test Workshop, Apr. 
v*7 10-11, Atlantic City, N.J. Cosponsor: 
IEEE Philadelphia Section. Contact Wesley E. 
Radcliffe, IBM E. Fishkill, Dept. 277, Bldg. 
321-5E1, Hopewell Junction, NY 12533, 
phone (914) 894-4346. 


Conf. on Computer Modeling in the Envi¬ 
ronmental Sciences, Apr. 10-11, Keyworth, 
UK. Cosponsors: Natural Environment Re¬ 
search Council, Inst, of Mathematics and its 
Applications. Contact G. Darwall, NERC, 
Holbrook House, Station Road, Swindon, 
Wilts, SN1 IDE, England. 


CHI 90, Human Factors in Computing Sys¬ 
tems 1990, Apr. 1-5, Seattle. Sponsor: ACM. 
Contact Toni MacHaffie, CHI 90, PO Box 
5847, Beaverton, OR 97006-5847, phone 
(503) 591-1981; or Assoc, for Computing Ma¬ 
chinery, 11 W. 42nd St., New York, NY 10036. 


Disco 90, Int’l Symp. on Design and Implem¬ 
entation of Symbolic Computation Systems, 
Apr. 10-12, Capri, Italy. Contact Alfonso Mi- 
ola, Dip. Informatica e Sistemistica, Via Buon¬ 
arroti, 12,00185 Roma, Italy, phone 39 (6) 
731-2367. 


Western Educational Computing Work¬ 
shops, Apr. 12-13, Northridge, Calif. Spon¬ 
sor: California Educational Computing Con¬ 
sortium. Contact Judah Rosenwald, Extended 
Education, NAD 153, San Francisco State 
Univ., 1600 Holloway, San Francisco, CA 
94132, phone (415) 338-1212. 

Applications of Artificial Intelligence 

VIII, Apr. 15-18, Orlando, Fla. Cospon¬ 
sor: SPIE. Contact Mohan M. Trivedi, Univ. of 
Tennessee, Electrical and Computer Engineer¬ 
ing, Ferris Hall, Knoxville, TN 37996-2100, 
phone (615) 974-5450. 

1990 Technical Symp. on Optical Engineer¬ 
ing and Photonics in Aerospace Sensing, 
Apr. 16-20, Orlando, Fla. Sponsor: SPIE. Con¬ 
tact Int’l Society for Optical Engineering, PO 
Box 10, Bellingham, WA 98227-0010, phone 
(206) 676-3290. 

|£j^| 13th IEEE Workshop on Design for 
'5*7 Testability, Apr. 17-20, Vail, Colo. 
Contact T.W. Williams, IBM, PO Box 1900, 
Dept. 67A/021B, Boulder, CO 80301-9191, 
phone (303) 924-7692. 


10th European Meeting on Cybernetics and 
Systems Research, Apr. 17-20, Vienna, Aus¬ 
tria. Sponsor: Austrian Society for Cybernetic 
Studies. Contact Robert Trappl, Cybernetics 
and Artificial Intelligence Dept., Univ. of Vi¬ 
enna, Freyung 6/2, A-1010 Vienna, Austria, 
phone 43 (222) 5353-2810. 


First Int’l Conf. on Systems Integra- 
n 57^ tion, Apr. 23-26, Morristown, N.J. 
Sponsor: New Jersey Inst, of Technology. 
Contact Peter A. Ng, Computer and Informa¬ 
tion Science Dept., New Jersey Inst, of Tech¬ 
nology, Newark, NJ 07102, phone (201) 596- 
3387. 


1990 Eastern Multiconf., Apr. 23-26, Nash¬ 
ville, Tenn. Sponsor: Society for Computer 
Simulation. Contact SCS, PO Box 17900, San 
Diego, CA 92117-7900, phone (619) 277- 
3888. 


First European Conf. on Computer Vision, 
Apr. 23-27, Antibes, France. Sponsor: INRIA. 
Contact C. Juncker, Institut National de Re¬ 
cherche en Informatique et en Automatique, 
Bureau des Relations Exterieures, Sophia An- 
tipolis, 2004, Route des Lucioles, 06565 
Valbonne Cedex, France, phone 33 (93) 65-78- 
60. 


COIS 90, Conf. on Office Information 
Systems, Apr. 25-27, Cambridge, Mass. 
Cosponsor: ACM. Contact Robert B. Allen, 
Rm. 2A-367, Bellcore, 444 South St., Morris¬ 
town, NJ 07960-1910, phone (201) 829-4280 
or 4315. 

SETA 1, First Int’l Symp. on Environ- 
ments and Tools for Ada, Apr. 30-May 

2, Redondo Beach, Calif. Cosponsor: ACM. 
Contact Stowe Boyd, Meridian Software Sys¬ 
tems, 23141 Verdugo Dr., Suite 105, Laguna 
Hills, CA 92653, phone (714) 727-0700, ext. 
222; or Dewayne E. Perry, AT&T Bell Labora¬ 
tories, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2529. 
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11th Structured Development Forum, Apr. 
30-May 3, San Diego, Calif. Contact Gail 
Phipps or Judith G. Hays, Computer Sciences 
Corp., 1321 Mercedes Dr., Hanover, MD 
21076, phone (301) 859-0400. 


May 1990 


IAAI 90, Second Conf. on Innovative Appli¬ 
cations of Artificial Intelligence, May 1-3, 

Washington, DC. Sponsor: American Assoc, 
for Artificial Intelligence. Contact AAAI, 445 
Burgess Dr., Menlo Park, CA 94025, phone 
(415) 328-3123. 

24th Carnahan Conf. on Security Technol¬ 
ogy, May 2-4, Lexington, Ky. Contact Glenna 
Vickers, Office of Engineering Continuing 
Education, Univ. of Kentucky, 305 Slone 
Bldg., Lexington, KY 40506-0053, phone 
(606) 257-4296. 

21st Pittsburgh Conf. on Modeling and 
Simulation, May 3-4, Pittsburgh. Sponsors: 
Univ. of Pittsburgh et al. Contact William G. 
Vogt or Marlin H. Mickle, Modeling and Simu¬ 
lation Conf., 348 Benedum Engineering Hall, 
Univ. of Pittsburgh, Pittsburgh, PA 15261. 

10th IEEE Symp. on Mass Storage Sys- 
terns, May 6-10, Monterey, Calif. Con¬ 
tact Bernard T. O’Lear, NCAR, PO Box 3000, 
Boulder, CO 80307, phone (303) 497-1268. 

CompEuro 90, IEEE Int’l Conf. on 
Computer Systems and Software En¬ 
gineering, May 7-9, Tel Aviv. Cosponsors: 
IEEE Region 8, IEEE Israel Section, IEEE 
Computer Society Israel Chapter. Contact 
CompEuro 90 Conf. Secretariat, c/o ORTRA, 2 
Kaufman St., PO Box 50432, Tel Aviv, 61500, 
Israel, phone 972 (3) 664-825. 

1990 IEEE Symp. on Research in Secu- 
v57 rity and Privacy, May 7-9, Oakland, 
Calif. Contact Deborah Cooper, Unisys, 5731 
Slauson Ave., Culver City, CA 90230, phone 
(213) 338-3727. 

AISIG 90, Fifth AI Systems in Govern 
ment Conf., May 7-11, Washington, 

DC. Cosponsors: Mitre et al. Contact Barry G. 
Silverman, Inst, for AI, George Washington 
Univ., 2021 K St., Suite 710, Washington, DC 
20006, phone (202) 676-5112. 

Fourth Int’l Symp. on Knowledge Engineer¬ 
ing, May 7-11, Barcelona, Spain. Sponsor: 
Madrid Polytechnic Univ. Contact Jose R. 
Chelala, ISKE, Alvarez de Baena, 3-2, 28006 
Madrid, Spain. 

JISI 90, Computer Science and Deci- 
sion Support, May 9-11, Tunis, Tunisia. 
Contact M. Ben Ahmed, ENSI, 16 rue Bolo, 
Montplaisir 1002, Tunis Le Belvedere, Tuni¬ 
sia, phone 216(1) 780-394. 

Seventh IEEE Workshop on Real- 
Time Operating Systems and Soft¬ 
ware, May 10-11, Charlottesville, Va. Co¬ 
sponsor: Office of Naval Research. Contact 


Robert P. Cook, Computer Science Dept., 
Univ. of Virginia, Thornton Hall, Charlottes¬ 
ville, VA 22903, phone (804) 924-7605. 

First IEEE Int’l Conf. on Applications of In¬ 
dustrial Electronics Systems, May 13-17, 

Jerusalem, Israel. Sponsor: IEEE Israel Sec¬ 
tion. Contact Moshe Harpaz, Kibbutz Ein- 
Carmel, D.N. Hof Carmel 30860, Israel, phone 
(972) 4-844410. 

Workshop on Interconnections 
'5*7 Within High-Speed Digital Systems, 
May 14-16, Santa Fe, N.M. Cosponsors: IEEE 
Communications Society et al. Contact Randal 
Moulic, IBM Research Div., PO Box 704, Rm. 
H4-A04, Yorktown Heights, NY 10598, phone 
(914) 789-7321. 

1990 Society for Information Display Int’l 
Symp., May 14-18, Las Vegas. Contact How¬ 
ard L. Funk, IBM Corp., 10/641 3B-60, Old Or¬ 
chard Rd., Armonk, NY 10504, phone (914) 
765-6409. 

43rd SPSE Conf., May 20-25, Rochester, 

N.Y. Sponsor: SPSE (Society for Imaging Sci¬ 
ence and Technology). Contact Michael M. 
Shahin, Xerox Corp., Webster Research Cen¬ 
ter, 800 Phillips Rd., 0114-38D, Webster, NY 
14580, phone (716) 422-2011. 

Fifth Conf. on Artificial Intelligence 
for Space Applications, May 22-23, 
Huntsville, Ala. Cosponsors: IEEE Computer 
Society Huntsville Chapter et al. Contact Con¬ 
tinuing Education Div., Univ. of Alabama in 
Huntsville, Tom Bevill Center 285-1, 
Huntsville, AL 35899, phone (800) 448-4035 
or (205) 895-6372. 

First Conf. on Visualization in Bio- 
medical Computing, May 22-25, At¬ 
lanta. Cosponsors: Nat’1 Science Foundation 
et al. Contact Norberto Ezguerra, Bioengineer¬ 
ing Center, Georgia Tech, Atlanta, GA 30332, 
phone (404) 894-7026 or 3964. 

SIGMetrics 90, May 22-25, Boulder, Colo. 
Sponsor: ACM. Contact Gary J. Nutt, Univ. of 
Colorado, Boulder, CO 80301; or Herb 
Schwetman, MCC, 3500 W. Balcones Center 
Dr., Austin, TX 78759, phone (512) 338-3428. 

20th Int’l Symp. on Multiple-Valued 
Logic, May 23-25, Charlotte, N.C. Con¬ 
tact George Epstein, Computer Science Dept., 
Univ. of North Carolina at Charlotte, 214 Ken¬ 
nedy Bldg., Charlotte, NC 28223, phone (704) 
547-4566; or Carolyn F. Blalock, Office of 
Continuing Education, Univ. of North Caro¬ 
lina at Charlotte, Charlotte, NC 28223, phone 
(704) 547-4861. 

1990 American Control Conf., May 23-25, 

San Diego, Calif. Sponsor: American Auto¬ 
matic Control Council. Contact Dagfinn 
Gangsaas, Boeing Advanced Systems, PO Box 
3707, MS 33-12, Seattle, WA 98124-2207, 
phone (206) 241-4348. 

ICCI 90, Int’l Conf. on Computing and In¬ 
formation, May 23-26, Niagara Falls, Can¬ 
ada. Sponsor: Natural Sciences and Engineer¬ 
ing Research Council of Canada. Contact Wal- 


/gjjt 17th Int’l Symp. on Computer Archi¬ 
val tecture, May 28-31, Seattle. Cosponsor: 
ACM. Contact Jean L. Baer or Larry Snyder, 
Univ. of Washington, Computer Science 
Dept., FR-35, Seattle, WA 98195, phone (206) 
543-1695. 

® Euro ASIC 90, May 28-June 1, Paris. 

Contact Gabriele Saucier, Institut Na¬ 
tional Polytechnique de Grenoble/CSI, 46, 
avenue Felix Viallet, 38931 Grenoble Cedex, 
France, phone 33 (!) 76-57-46-87. 

ICDCS 10, 10th Int’l Conf. on Distrib- 
vST’ uted Computing Systems, May 28- 
June 1, Paris. Cosponsor: INRIA. Contact R. 
Popescu-Zeletin, GMD-FOKUS, Harden- 
bergplatz 2, D-1000 Berlin 12, West Germany, 
phone 49 (30) 25499-206; Jack Stankovic, 
Computer and Information Science Dept., 
Univ. of Massachusetts, Amherst, MA 01003, 
phone (413) 545-0720; or ICDCS 10, IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 

11th Conf. of the Canadian Applied Mathe¬ 
matics Society, May 29-June 1, Halifax, N.S., 
Canada. Cosponsors: CAMS et al. Contact 
Mary Meidell, Continuing Education Dept., 
Technical Univ. of Nova Scotia, PO Box 1000, 
Halifax, NS, Canada B3J 2X4, phone (902) 
429-8300, ext. 2420. 


June 1990 


CBMS 90, Third IEEE Symp. on Com- 
\g£' puter-Based Medical Systems, June 3- 

6, Chapel Hill, N.C. Cosponsor: IEEE Engi¬ 
neering in Medicine and Biology Society. 
Contact James N. Brown, Jr., Research Tri¬ 
angle Inst., 3040 Cornwallis, Research Tri¬ 
angle Park, NC 27709, phone (919) 541-9675. 

Spring Comdex, June 3-6, Atlanta. Contact 
Interface Group, 300 First Ave., Needham, 

MA 02194, phone (617) 449-6600. 

IEEE Infocom 90, Ninth Conf. on 
Computer Communications, June 3-7, 

San Francisco. Cosponsor: IEEE Communica¬ 
tions Society. Contact Infocom 90, IEEE Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

LICS 90, Fifth Symp. on Logic in Com- 
v«7 puter Science, June 4-7, Philadelphia. 
Contact Albert Meyer, Computer Science Lab, 
545 Technology Square, NE 43-315, Cam¬ 
bridge, MA 02139, phone (617) 253-6024. 

fflj Int’l Workshop on Rapid System 
Prototyping, June 5-7, Triangle Re¬ 
search Park, N.C. Contact Kenneth Anderson, 
Siemens Corporate Research, 755 College Rd. 
E., Princeton, NJ 08540, phone (609) 734- 
6550. 
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Eurographics Workshop on Object-Ori¬ 
ented Graphics, June 6-8, Konigswinter, 
Federal Republic of Germany. Sponsors: Eu¬ 
rographics and German Society for Infor¬ 
matics. Contact Marja Hegt, 0-0 Graphics 
Workshop, CWI, Kruislaan 413, 1098 SJ Am¬ 
sterdam, The Netherlands, phone 31 (20) 592- 
4058. 


ACL 90,28th Conf. of the Assoc, for Compu¬ 
tational Linguistics, June 6-9, Pittsburgh. 
Contact Don Walker, Bellcore, MRE 2A379, 
445 South St., Box 1910, Morristown, NJ 
07960-1910, phone (201) 829-4312. 


|£j^i Computer Security Foundations III, 
June 10-12, Franconia, N.H. Contact 
Tom Haigh, SCTC, 2855 Anthony Lane South, 
St. Anthony, MN 55418, phone (612) 782- 
7145. 


1990 European Simulation Multiconf., June 
10-13, Nuremberg, Federal Republic of Ger¬ 
many. Sponsor: Society for Computer Simula¬ 
tion Int’l. Contact Bemd Schmidt, Univ. Er¬ 
langen, Computer Science Dept., D-8520, Er¬ 
langen, FRG, phone (49) 9131-857-278; or 
SCS Int’l, c/o Philippe Geril, Coupure Links 
653, B-9000 Ghent, Belgium, phone (32) 91- 
23-69-61. 


Int’l Workshop on Algorithms and Parallel 
VLSI Architectures, June 10-16, Pont-a- 
Mousson, France. Cosponsors: IEEE, Eurasip. 
Contact Alle-Jan van der Veen, Electrical En¬ 
gineering Dept., Delft Univ. of Technology, 
2628 CD Delft, The Netherlands, phone (31) 
1578-1442. 

IFIP Workshop on Design and Test of 
ASICs, June 11-12, Hiroshima, Japan. 
Cosponsors: Information Processing Society 
of Japan et al. Contact Kozo Kinoshita, Hiro¬ 
shima Univ., 1-1-80 Higashisendacho, Naka- 
ku, Hiroshima-shi 730, Japan, phone 81 (87) 
249-9150. 

19th Mumps Users’ Group Meeting, June 
11-15, Orlando, Fla. Contact Mumps Users’ 
Group, 4321 Hartwick Rd., Suite 100, College 
Park, MD 20740, phone (301) 779-6555. 

1990 ACM Int’l Conf. on Supercomputing, 
June 11-15, Amsterdam. Contact E. Gallopou- 
los, Univ. of Illinois CSRD, 305 Talbot Lab, 

104 S. Wright St., Urbana, IL 61801-2932 (for 
North and South America); John R. Gurd, 
Computer Science Dept., Univ. of Manchester, 
Oxford Road, Manchester M13 9PL, UK (Eu¬ 
rope and Africa); or Yoichi Muraoka, Electri¬ 
cal Engineering Dept., Waseda Univ., 3-4-1 
Okubo, Shinjuku-ku, Tokyo, Japan (Japan and 
the Far East). 

Usenix Summer 1990 Technical Conf., June 
11-15, Anaheim. Contact John R. Mashey, 
Anaheim Usenix Technical Program, MIPS 
Computer Systems, 930 Arques Ave., Sunny¬ 
vale, CA 94086, phone (408) 991-0253. 

Ninth Int’l Conf. on Analysis and Optimiza¬ 
tion of Systems, June 12-15, Antibes, France. 
Sponsor: INRIA. Contact Conf. Secretariat, 
1NRIA, Service des Relations Exterieures, 
Domaine de Voluceau—BP 105, 78153 Le 
Chesnay Cedex, France, phone 33 (l)-39-63- 
5500. 


IAPR Workshop on Syntactic and Struc¬ 
tural Pattern Recognition, June 13-15, Mur¬ 
ray Hill, N.J. Sponsor: Int’l Assoc, for Pattern 
Recognition. Contact Henry S. Baird, AT&T 
Bell Laboratories, Rm. 2C-557, 600 Mountain 
Ave., Murray Hill, NJ 07974, phone (201) 582- 
5744. 

10th Int’l Symp. on Protocol Specification, 
Testing, and Verification, June 13-15, Ot¬ 
tawa, Ont., Canada. Sponsor: IFIP. Contact 
Luigi Logrippo, Computer Science Dept., 
Univ. of Ottawa, Ottawa, Ont., Canada KIN 
6N5. 

IAPR TC7 Workshop on Multisource Data 
Integration in Remote Sensing, June 14-15, 

College Park, Md. Cosponsors: International 
Assoc, for Pattern Recognition, NASA God¬ 
dard Space Flight Center. Contact James C. 
Tilton, MC 636, NASA Goddard Space Flight 
Center, Greenbelt, MD 20771, phone (301) 
286-9510. 


Third Int’l Symp. on Image Conservation, 
June 17-20, Rochester, N.Y. Sponsor: Society 
for Imaging Science and Technology. Contact 
Charlton Bard, 74 Cornwall Lane, Rochester, 
NY 14617, phone (716) 342-3174. 


ICPR 90, 10th Int’l Conf. on Pattern 
Recognition, June 17-21, Atlantic City, 
N.J. Contact Herbert Freeman, CAIP Center, 
605 Hill, Rutgers Univ., New Brunswick, NJ 
08903, phone (201) 932-4208. 


Third IFIP Workshop on Geometric Model¬ 
ing, June 17-21, Rensselaerville, N.Y. Con¬ 
tact Mary Johnson, Rensselaer Design Re¬ 
search Center, Rensselaer Polytechnic Inst., 
Troy, NY 12180-3590, phone (518) 276-6751. 


IJCNN 90,1990 Int’l Joint Conf. on Neural 
Networks, June 17-21, San Diego, Calif. Co¬ 
sponsors: IEEE, Int’l Neural Network Society. 
Contact Nomi Feldman, UCNN, 5665 Oberlin 
Dr., Suite 110, San Diego, CA 92121. 


EDFT, Seventh European Workshop 
on Design for Testability, June 18-20, 

Segovia, Spain. Contact T.W. Williams or C. 
Lopez Barrio, IBM, PO Box 1900, Dept. AJA/ 
021B, Boulder, CO 80301-9191, phone (303) 
924-7692. 


Dr., Suite 180, Annapolis, MD 21401, phone 
(301) 266-8244. 

Second Int’l Conf. on Software Engineering 
and Knowledge Engineering, June 21-23, 

Skokie, Ill. Sponsors: Knowledge Systems 
Inst., Univ. of Pittsburgh, and Inst, for Infor¬ 
mation Industries, Taiwan. Contact Shi-Kuo 
Chang, Computer Science Dept., Univ. of 
Pittsburgh, 322 Alumni Hall, Pittsburgh, PA 
15260, phone (412) 624-8490. 

NECC 90, 11th Nat’l Educational Comput¬ 
ing Conf., June 25-27, Nashville, Term. Spon¬ 
sor: Int’l Council for Computers in Education. 
Contact John D. McGregor, Computer Studies 
Dept., Murray State Univ., Murray, KY 42071, 
phone (502) 762-2614. 

DAC 90, 27th ACM/IEEE Design 
Automation Conf., June 25-29, 

Orlando, Fla. Contact Pat Pistilli, MP Associ¬ 
ates, 7490 Clubhouse Rd., Suite 102, Boulder, 
CO 80301, phone (303) 530-4333. 

Int’l Symp. on Fuzzy Approach to Rea- 
soning and Decision Making, June 25- 

29, Bechyne, Czechoslovakia. Cosponsor: 
Int’l Fuzzy System Assoc. Contact Vilem No¬ 
vak, Minin Inst., Czechoslovakia Academy of 
Sciences, A. Rimana 1768, 70800 Ostrava- 
Poruba, Czechoslovakia. 

Advanced Research Workshop on 3D Imag¬ 
ing in Medicine, June 25-29, Travemuende, 
Federal Republic of Germany. Sponsor: 
NATO. Contact Linda Houseman, Computer 
Science Dept., Univ. of North Carolina, Box 
3175, Sitterson Hall, Chapel Hill, NC 27599, 
phone (919) 962-1758 (for the Americas); or 
Andreas Pommert, Inst, fur Mathematik und 
Datenverarbeitung in der Medizin, Univ. 
Krankenhaus Eppendorf, Martinistrasse 52, 
2000 Hamburg 20, Federal Republic of Ger¬ 
many, phone 49 (40) 468-2300 (for Europe, 
Asia, Australia, and Africa). 


EKAW 90, Fourth European Knowledge 
Acquisition for Knowledge-Based Systems 
Workshop, June 25-29, Amsterdam. Contact 
John H. Boose, Advanced Technology Center, 
Boeing Computer Services 7L-64, PO Box 
24346, Seattle, WA 98124, phone (206) 865- 
3253. 


IMSC 90, Int’l Mobile Satellite Conf., June 
18-20, Ottawa, Canada. Cosponsors: NASA, 
Canadian Dept, of Communications. Contact 
IMSC 90 Organizing Committee, c/o D. Hugh 
M. Reekie, Dept, of Communications, 300 
Slater St., Ottawa, Ont., Canada K1A 0C8. 

Workshop on Computer-Aided Verifica¬ 
tion, June 18-20, Princeton, N.J. Contact E.M. 
Clarke, Computer Science Dept., Carnegie 
Mellon Univ., Pittsburgh, PA 15213-3890; 
R.P. Kurshan, AT&T Bell Labs, Rm. 2C-353, 
Murray Hill, NJ 07974; A. Pnueli, Weizmann 
Inst., Rehovot, Israel; or J. Sifakis, LGI- 
IMAG, BP 53X, 38041 Grenotle Cedex, 

Seventh Int’l Conf. on Testing Computer 
Software, June 18-21, San Francisco. Contact 
Genevieve Houston-Ludlam, ISTC 90, c/o 
Frontier Technologies, 190 Admiral Cochran 


£3^ FTCS 20, 20th Int’l Symp. on Fault- 
Tolerant Computing, June 26-28, 

Newcastle upon Tyne, England. Cosponsors: 
Centre for Software Reliability, British Com¬ 
puter Society, IEE. Contact Neil Speirs, Com¬ 
puting Lab, Univ. of Newcastle upon Tyne, 
Newcastle upon Tyne, NE1 7RU, UK, phone 
44 (91) 232-8511. 


Compass 90, Fifth Conf. on Computer As¬ 
surance: Systems Integrity, Software 
Safety, and Process Security, June 26-29, 
Gaithersburg, Md. Cosponsors: IEEE Aero¬ 
space and Electronics Society, IEEE National 
Capital Area Council. Contact Dolores Wal¬ 
lace, National Inst, of Standards and Technol¬ 
ogy, Gaithersburg, MD 20899; (301) 975- 
3340. 
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gapore. Sponsors: Computer Graphics Soci¬ 
ety, Inst, of Systems Science, Singapore. Con¬ 
tact Juzar Motiwalla, CGI 90, ISS, Nat’1 Univ. 
of Singapore, Kent Ridge, Singapore 0511, 
phone (65) 772-2075. 

1990 ACM Conf. on Lisp and Functional 
Programming, June 27-29, Nice, France. 
Contact Gillies Kahn, INRIA Sophia — Anti- 
polis, 2004 Route des Lucioles, 06565 Val- 
bonne Cedex, France, phone (33) 93-65-78-01. 


Fifth Rocky Mountain Conf. on Artifi- 
V57 cial Intelligence, June 28-30, Las 

Cruces, N.M. Cosponsors: ACM et al. Contact 
Paul McKevitt, Computing Research Lab, 
Dept. 3CRL, Box 30001, New Mexico State 
Univ., Las Cruces, NM 88003-0001, phone 
(505) 646-5109. 


July 1990 


Roundtable Discussion on Vision-Based 
Vehicle Guidance, July 2, Tokyo. Sponsor: 
Committee of IEEE Int’l Workshop on Intelli¬ 
gent Robots and Systems. Contact Ichiro 
Masaki, Computer Science Dept., GM Re¬ 
search Labs, 30500 Mound Rd., Warren, MI 
48090-9055, phone (313) 986-1466. 


i£ji| Second Int’l Symp. on Databases in 
Parallel and Distributed Systems, July 
2-4, Dublin, Ireland. Cosponsor: ACM. Con¬ 
tact Rakesh Agrawal, AT&T Bell Labs, Rm. 
3D450, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2250; or David Bell, 
Inst, of Informatics, Univ. of Ulster, Jordans- 
town, County Antrim, Northern Ireland 
BT370QB, phone (0232) 365-131. 


Second Int’l Conf. on Economics and 
Artificial Intelligence, July 2-6, Paris. 
Sponsor: AFCET. Contact J-L. Le Moigne, 
GRASCE, Univ. Aix Marseille III, 3, ave. 
Robert Schuman, 13628, Aix en Provence, 
France; or P. Bourgine, 26, rue St. Louis, 
78000, Versailles, France. 


SPAA 90, Second ACM Symp. on Par- 
'5*7 allel Algorithms and Architecture, 
July 2-6, Crete, Greece. Cosponsor: ACM. 
Contact Tom Leighton, MIT, Cambridge, MA 
02139, phone (617) 253-3662. 


Fourth TC2 Working Conf. on Database 
Semantics, July 2-6, Windermere Lake Dis¬ 
trict, UK. Sponsor: IFIP, Coopers and Lybrand 
UK. Contact William Kent, Hewlett-Packard 
Labs, Dept. 3U, 1501 Page Mill Rd., Palo Alto, 
CA 94304-0971; or Robert Meersman, In- 
folab, Tilburg Univ., PO Box 90153, 5000 LE 
Tilburg, The Netherlands. 


WCCE 90, Fifth World Conf. on Com- 
puters in Education, July 9-13, 

Sydney, Australia. Cosponsors: IFIP et al. 
Contact WCCE 90, PO Box 319, Darlinghurst, 
NSW 2010, Australia, phone (612) 211-5855. 


Iberamia 90, Second Ibero-American Conf. 
on Al, July 9-13, Morelia, Michoacan, Mex¬ 


ico. Sponsors: Centro Regional de Ensenanza 
en Informatica (Spain) et al. Contact Iberamia 
90, Atn. Srita. Ma. Antonieta Alvarez Perez, 
Apartado Postal 70302, C.P. 04510, Mexico, 
D.F. 


Third Int’l Conf. on Industrial and 
xgy Engineering Applications for Al and 
Expert Systems, July 15-18, Charleston, S.C. 
Cosponsors: ACM et al. Contact Moonis Ali, 
Univ. of Tennessee Space Inst., MS15, Tulla- 
homa, TN 37388, phone (615) 455-0631. 


1990 Summer Computer Simulation Conf., 
July 16-18, Calgary, Alta., Canada. Sponsor: 
Society for Computer Simulation. Contact 
SCS, PO Box 17900, San Diego, CA 92117- 
7900, phone (619) 277-3888. 


ICALP 90, 17th Int’l Colloquium on Auto¬ 
mata, Languages, and Programming, July 
16-20, Coventry, England. Sponsor: Int’l 
Computers, Ltd. Contact Computer Science 
Dept., Univ. of Warwick, Coventry CV4 7AL, 
UK, phone 44 (203) 523-194. 


Int’l Workshop on Semantics for Concur¬ 
rency, July 23-25, Leicester, UK. Sponsor: 
British Computer Society. Contact Marta 
Kwiatowska, Workshop on Semantics for 
Concurrency, Computing Studies Dept., Univ. 
of Leicester, Leicester LEI 7RH, UK, phone 
(44) 533-523603. 


10th Int’l Conf. in Computer Science, July 
23-27, Santiago, Chile. Contact Joachim von 
zur Gathen, Computer Science Dept., Univ. of 
Toronto, 10 King’s College Rd., Toronto, Can¬ 
ada M5S 1A4, phone (416) 978-6024. 


DIAC 90, Directions and Implications of 
Advanced Computing, July 28, Boston. 
Sponsor: Computer Professionals for Social 
Responsibility. Contact Douglas Schuler, 
Boeing Computer Services, MS 7L-64, PO 
24346, Seattle, WA 98124-0346, phone (206) 
634-2771. 

AAAI 90 Workshop of the National Conf. on 
Al, July 31-Aug. 3, Boston. Sponsor: Ameri¬ 
can Assoc, for Artificial Intelligence. Contact 
Edward Lafferty, Al Center, Mitre, MS A350, 
Burlington Rd., Bedford, MA 01730, phone 
(617) 271-2773. 


August 1990 


SIGComm 90 Conf., Aug. 1-5, Philadelphia. 
Sponsor: ACM SIGComm. Contact Phil Kam, 
Bell Communications Research, MS 2P-357, 
445 South St., PO Box 1910, Morristown, NJ 
07962-1910, phone (201) 829-4299. 

/£3^v SIGGraph 90, 17th Conf. on Com- 
^§7 puter Graphics and Interactive Tech¬ 
niques, Aug. 6-10, Dallas. Cosponsor: ACM. 
Contact Assoc, for Computing Machinery, 11 
W. 42nd St., New York, NY 10036, phone 
(212) 869-7440. 


16th Int’l Conf. on Very Large Data Bases, 
Aug. 13-16, Brisbane, Australia. Contact 
David Reiner, Lotus Development, 1 Canal 
Park, Cambridge, MA 02141, phone (617) 
577-8500. ‘ 

ICPP 90,19th Int’l Conf. on Parallel Proc¬ 
essing, Aug. 13-17, St. Charles, III. Sponsor: 
Pennsylvania State Univ. Contact Tse-yun 
Feng, EE East Bldg., Pennsylvania State Univ. 
University Park, PA 16802, phone (814) 863- 
1469. 

Int’l Symp. on Algorithms, Aug. 16-18, To¬ 
kyo. Sponsor: IPSJ Special Interest Group on 
Algorithms. Contact Tetsuo Asano, Osaka 
Electro-Communication Univ., Hatsu-cho, 
Nayagawa, Osaka 572, Japan, phone 81 (720) 
24-1131. 


September 1990 


ISPRS Commission V Symp., Close- 
^*7 Range Photogrammetry Meets Ma¬ 
chine Vision, Sept. 3-7, Zurich. Cosponsor: 
Int’l Society for Photogrammetry and Remote 
Sensing et al. Contact Armin Gruen, Inst, of 
Geodesy and Photogrammetry, ETH-Hoeng- 
gerberg, CH-8093, Zurich, Switzerland, 
phone 41 (1) 377-3051. 

Zgj ASAP 90, Int’l Conf. on Application- 
^§7 Specific Array Processors, Sept. 5-7, 
Princeton, NJ. Cosponsor: Princeton Univ. 
Contact S.Y. Kung, Electrical Engineering 
Dept., Princeton Univ., Princeton, NJ 08544, 
phone (609) 258-3780. 

ITC 90, Int’l Test Conf., Sept. 10-12, 

'^§7 Washington, DC. Cosponsor: IEEE Phil¬ 
adelphia Section. Contact Donald Denburg, 
AT&T Bell Labs, 1247 S. Cedar Crest Blvd., 
Allentown, PA 18103; or ITC, 1201 Sussex 
Turnpike, Suite 101, PO Box 264, Mt. Free¬ 
dom, NJ 07970, phone (201) 895-5260. 

ZS^.IEEE Conf. on Managing Expert Sys- 
^■7 tern Programs and Projects, Sept. 10- 

12, Washington, DC. Sponsor: IEEE Com¬ 
puter Society Task Force on Expert Systems. 
Contact Jay Liebowitz, Management Sciences 
Dept., George Washington Univ., Washing¬ 
ton, DC, phone (202) 994-6969. 

ZS^, ICCD 90, IEEE Int’l Conf. on Com- 
'^■7 puter Design: VLSI in Computers and 
Processors, Sept. 16-19, Cambridge, Mass. 
Contact Edward M. Middlesworth, Hewlett- 
Packard, Bldg. 25U, PO Box 10350, Palo Alto, 
CA 94303-0867, phone (415) 857-5485; or 
ICCD 90, IEEE Computer Society, 1730 Mas¬ 
sachusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 

Electronic Publishing 90, Sept. 18-20, 

'^§7 Gaithersburg, Md. Sponsor: NIST. Con¬ 
tact Peter R. King, Computer Science Dept., 
Univ. of Manitoba, Winnipeg, Manitoba, Can¬ 
ada R3T 2N2, phone (204) 474-9935. 

Computational Intelligence 90, Sept. 
^17 27-29, Milano, Italy. Sponsors: F.I.S. 
Cassa di Rosp. o. PC. Contact Giorgio Valle, 
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,£|N. Future Trends 90, Workshop on Fu- 
'5*7 ture Trends of Distributed Computing 
Systems, Sept. 30-Oct. 2, Cairo. Contact 
Stephen S. Yau, Univ. of Florida, CIS Dept., 
Rm. 301, Gainesville, FL 32611, phone (904) 
335-8006. 


October 1990 


15th Conf. on Local Computer Net- 
*5*7 working, Oct. 1-3, Minneapolis, Minn. 
Contact Marc Cohn, Advanced Development 
Div., Raychem Corp., 300 Constitution Dr., 
Menlo Park, CA 94025-1164, phone (415) 
361-3902. 

Infojapan 90, lnt’1 Conf. on Informa- 
*5*7 tion Technology, Oct. 1-5, Tokyo. 
Sponsor: IPSJ. Contact Takuma Yamamoto, 
Fujitsu, 3-14-1 Hiyoshi, Kohoku-ku, Yokoha- 
mashi, Japan. 

Sixth Int’l Conf. on the Application of 
*5*7 Standards for Open Systems Intercon¬ 
nection, Oct. 2-4, Gaithersburg, Md. Cospon¬ 
sor: National Inst, of Standards and Technol¬ 
ogy. Contact Brenda Gray, NIST/OSI, Rm. 
B217, Bldg. 225, Gaithersburg, MD 20899, 
phone (301) 975-3664. 

Frontiers 90, Third Symp. on Fron- 
\*7 tiers of Massively Parallel Computa¬ 
tion, Oct. 8-10, College Park, Md. Cosponsor: 
NASA Goddard Space Flight Center. Contact 
Johanna Weinstein, Frontiers 90, UMIACS, 
Univ. of Maryland, A.V. Williams Bldg., Col¬ 
lege Park, MD 20742, phone (301) 454-1808. 

Ninth Symp. on Reliable Distributed 
'5*7 Systems, Oct. 9-11, Huntsville, Ala. 
Contact Raif M. Yanney, TRW, MS DH2/ 

2328, 1 Space Park, Redondo Beach, CA 
90278, phone (213) 764-6033. 

£2^, OOPSLA 90, Fifth Conf. on Object- 
'5*7 Oriented Programming Systems, Lan¬ 
guages, and Applications, Oct. 21-25, Ot¬ 
tawa, Canada. Cosponsor: ACM. Contact 
Assoc, for Computing Machinery, 11 W. 42nd 
St., New York, NY 10036, phone (212) 869- 
7440. 

JCIT 5, Fifth Jerusalem Conf. on In- 
'5*7 formation Technology, Oct. 22-25, 

Jerusalem, Israel. Sponsor: Information Pro¬ 
cessing Assoc, of Israel. Contact Abraham 
Peled, IBM T.J. Watson Research Center, PO 
Box 704, Yorktown Heights, NY 10598. 

Visualization 90, Oct. 23-26, San Fran- 
\S7 cisco. Contact Bruce Brown, Oracle 
Corp., 20 Davis Dr., Belmont, CA 94002, 
phone (415) 598-3628. 

Workshop on the Management of Rep- 
*5*7 licated Data, Oct. 24-26, Houston. Con¬ 
tact Luis-Felipe Cabrera, 650 Harry Rd., MC 
K55/803, San Jose, CA 95120-6099, phone 
(408) 927-1838. 


ESORICS 90, European Symp. on Re- 
'5*7 search in Computer Security, Oct. 24- 

26, Toulouse, France. Cosponsor: AFCET. 
Contact Martin Gilles, 16 Para de Diane, 78350 
Jouy eu Josas, Toulouse Cedex, France. 

Int’l Conf. on Information Technology, Oct. 
29-31, Bournemouth, UK. Sponsor: Institu¬ 
tion of Electrical Engineers. Contact IEE Conf. 
Services, Savoy PI., London WC2R 0BL, UK, 
phone 44 (1) 24-01-871. 

Compsac 90, 14th Int’l Computer 
’5*7' Software and Applications Conf., Oct. 
31-Nov. 2, Chicago. Contact Ifay F. Chang, 
Rm. 1B28, IBM T.J. Watson Research Center, 
PO Box 714, Yorktown Heights, NY 10595, 
phone (914) 789-7825. 


November 1990 


(£2^, 14th SCAMC, 1990 Symp. on Com- 
'5*7 puter Applications in Medical Care, 
Nov. 4-7, Washington, DC. Cosponsors: 
George Washington Univ. Medical Center 
et al. Contact SCAMC — Office of CEM, 
George Washington Univ. Medical Center, 
2300 K St. NW, Washington, DC 20037, phone 
(202) 994-8928. 

Intelligent Robotic Systems: Design 
'5*7 and Applications, Nov. 6-7, Philadel¬ 
phia. Sponsor: SPIE. Contact Mohan M. Tri- 
vedi, Univ. of Tennessee, Electrical and Com¬ 
puter Engineering, Ferris Hall, Knoxville, TN 
37996-2100, phone (615) 974-5450. 

TAI 90, Second Computer Society 
'5*7 Int’l Conf. on Tools for Artificial Intel¬ 
ligence, Nov. 6-9, Washington, DC. Cospon¬ 
sors: Rutgers Univ. et al. Contact Nikolas G. 
Bourbakis, George Mason Univ., ECE Dept., 
Fairfax, VA 22030, phone (703) 425-3930. 

ICCAD 90, IEEE Int’l Conf. on Com- 
*5*7 puter-Aided Design, Nov. 12-15, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Society. Contact ICCAD 90, IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 

Supercomputing 90, Nov. 12-16, New 

^■7 York City. Cosponsor: ACM. Contact 
Joanne L. Martin, IBM T.J. Watson Research 
Center, PO Box 218, Route 134, Yorktown 
Heights, NY 10698, phone (914) 945-3285; or 
Supercomputing 90, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 

Fall Comdex, Nov. 13-17, Las Vegas. Contact 
Interface Group, 300 First Ave., Needham, 

MA 02194, phone (617) 449-6600. 

Cognitiva 90, Nov. 20-23, Madrid. 

'5*7 Sponsor: AFCET. Contact Cognitiva 90, 
c/o AFCET, 156 Bd Pereire, 75017 Paris, 
France, phone 33 (01) 47-66-24-19. 

Z2N. 1990 Conf. on Software Maintenance, 
'5*7 Nov. 26-29, San Diego, Calif. Contact 
Thomas M. Pigoski, USN, NSGD Pensacola, 


Micro 23, 23rd Symp. and Workshop 
*5*7 on Microprogramming and Micro¬ 
architecture, Nov. 27-29, Orlando, Fla. Co¬ 
sponsor: ACM. Contact Chris Papachristou, 
Case Western Reserve Univ., Computer Engi¬ 
neering and Science Dept., Cleveland, OH 
44106, phone (216) 368-5277. 


December 1990 

First Int’l Symp. on Uncertainty and 
^*7 Analysis: Fuzzy Reasoning, Probabil¬ 
istic Methods, and Risk Management, Dec. 
3-5, College Park, Md. Sponsors: Univ. of 
Maryland et al. Contact Bilal M. Ayyub, Civil 
Engineering Dept., Univ. of Maryland, Col¬ 
lege Park, MD 20742. 

ACM SIGSoft 90, Fourth Symp. on 
^*7 Software Development Environ¬ 
ments, Dec. 3-5, Irvine, Calif. Cosponsor: 
ACM. Contact Dewayne E. Perry, AT&T Bell 
Labs, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2529. 

ICCV 90, Third Int’l Conf. on Com- 
'5*7 puter Vision, Dec. 4-7, Osaka, Japan. 
Contact ICCV 90, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 

,£1^111th Real-Time Systems Symp., Dec. 
*5*7 5-7, Orlando, Fla. Contact Doug Locke, 
IBM — MS 409, Systems Integration Div., 
6600 Rockledge Dr., Bethesda, MD 20817, 
phone (301) 493-1496. 

CASE 90, Fourth Int’l Workshop on 
*5*7 Computer-Aided Software Engineer¬ 
ing, Dec. 5-8, Irvine, Calif. Contact Elliott J. 
Chikofsky, Radius Systems, 75 Lexington St„ 
Burlington, MA 01803, phone (617) 494- 
8200. 

<£S^l Second IEEE Symp. on Parallel and 
N*7 Distributed Processing, Dec. 10-12, 

Dallas. Sponsor: Dallas Section of the IEEE 
Computer Society. Contact Behrooz Shirazi, 
Computer Science and Engineering Dept., 
Southern Methodist Univ., Dallas, TX 75275, 
phone (214) 692-2874. 


February 1991 


CAIA 91, Seventh IEEE Conf. on Arti- 
*5*7 ficial Intelligence Applications, Feb. 
24-28, Miami Beach, Fla. Contact IEEE Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

Compcon Spring 91, Feb. 25-Mar. 1, 

*5*7 San Francisco. Contact Compcon Spring 
91, IEEE Computer Society, 1730 Massachu¬ 
setts Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 


February 1990 
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CAREER OPPORTUNITIES 


RATES: $12.00 per line, $120 
minimum charge (up to ten lines). 
Average five typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing, COMPUTER Magazine, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 


THE UNIVERSITY OF TEXAS 
AT ARLINGTON 

The Department of Computer Science 
Engineering at The University of Texas at Ar¬ 
lington invites applications for tenure-track 
or visiting faculty positions in all areas of 
computer science or computer engineering. 
Applicants with expertise relating to reliable 
real-time distributed systems, telecommuni¬ 
cations software, object-oriented systems, 
machine vision, knowledge-based systems, 
or parallel processing will be given highest 
priority. Rank is open. An earned doctorate 
or equivalent and a commitment to teaching 
and scholarly research are required. Open¬ 
ings are expected for September 1990. Ap¬ 
plications received prior to March 1, 1990 
will receive full consideration. Interested per¬ 
sons should send a resume to Bill D. Carroll, 
Professor and Chairperson, Computer Sci¬ 
ence Engineering Department, P.O. Box 
19015, The University of Texas at Arlington, 
Arlington, TX 76019. Phone 817-273-3785. 
FAX 817-273-2548. 

The University of Texas at Arlington is an 
Equal Opportunity Affirmative Action 
Employer. 


UNIVERSITY OF MINNESOTA- 
DULUTH 

Applications are invited for the Jack Rowe 
Professorship in Engineering. This is a 
tenured or multiple year special contract at 
the rank of full professor. Responsibilities: 
develop curriculum toward a proposed de¬ 
gree in electrical engineering (50% teaching, 
50% outreach and research). Qualifications: 
doctorate in electrical engineering or related 
field plus a minimum of ten years post¬ 
degree relevant teaching and/or industrial 
experience in the United States. Interest and 
expertise in power and system engineering is 
particularly desirable. Demonstrated evi¬ 
dence of effective teaching and communica¬ 
tion skills appropriate to a faculty member is 
required. Must be eligible for employment in 
the United States at the time of application. 
Salary: competitive. Beginning date of ap¬ 
pointment: September 1, 1990. Applica¬ 
tions must be received by April 2, 1990. 
Send to: James R. Johnson, chair, Jack 
Rowe Professorship Search Committee, 
College of Science and Engineering, 140 
Engineering Building, University of Minne¬ 
sota, Duluth MN 55812. The University of 
Minnesota is an equal opportunity educator 
and employer and welcomes applications 
from women and minorities. 


UNIVERSITY OF CALIFORNIA, 
DAVIS 

Faculty Positions in Electrical 

Engineering and Computer Science 

The Department of Electrical Engineering 
and Computer Science at UC Davis invites 
applications for tenure track positions at all 
ranks. The primary areas of interest are 
image processing and computer vision; op¬ 
toelectronics; and computer engineering 
and microprocessor applications. 

The department, with 50 faculty members 
and 180 full-time graduate students, is ex¬ 
periencing rapid growth. Our College is the 
nation’s sixteenth largest producer of engi¬ 
neering Ph.D.’s in a University which has the 
nineteenth largest extramural research fund¬ 
ing. Salary and benefits are extremely 
attractive. 

Davis is a pleasant, family-oriented com¬ 
munity near Sacramento, within easy driving 
distance to Silicon Valley, the Lawrence 
Livermore National Laboratory, San Fran¬ 
cisco, the Pacific Ocean, and the Sierra 
Nevada Mountains. 

We are seeking individuals with strong 
records of teaching and research and with 
ambitious plans. Senior appointments re¬ 
quire outstanding records of achievement; 
junior apppointments must show evidence 
of great promise. All faculty are expected to 
have a strong commitment to teaching at all 
degree levels, and to demonstrate the ability 
to attract significant research support. 

The positions require a Ph.D. degree or 
equivalent, and are open until filled. Send a 
resume and the names of at least three 
references to: 

Professor S. Louis Hakimi, Chair 

Attention: Faculty Search Committee 

Department of Electrical Engineering 
and Computer Science 

University of California 

Davis, CA 95616 

The University of California, Davis, is an 
equal opportunity/affirmative action 
employer. 


PRAIRIE VIEW A&M UNIVERSITY 
Computer Science Faculty Position 

The College of Applied Sciences and 
Engineering Technology at Prairie View 
A&M University has a tenure-track faculty 
position in Computer Science starting Fall 
1990. Ph.D. in Computer Science required. 
Rank and salary to commensurate with qual¬ 
ifications. Applications will be accepted until 
the position is filled. The screening will start 
on April 1, 1990. Send resume with names 
of three references to: 

Mr. J.D. Oliver, Coordinator 
Computer Science Program 
Prairie View A&M University 
P.O. Box 308 
Prairie View, TX 77446 
An Equal Opportunity/Affirmative Action 
Employer. 


UNIVERSITY OF NEVADA 
LAS VEGAS 

The Computer Science Department in¬ 
vites applications for tenure track faculty 
positions in Computer Science. Applicants 
should have a Ph.D. in Computer Science or 
a related area and a commitment to excel¬ 
lence in teaching and research. Our principle 
needs are in the areas of Programming Lan¬ 
guage Semantics or Programming Language 
Design. Full-time research positions may 
also be available in the Neural Nets/Pattern 
Recognition and Database/Information Re¬ 
vival areas. Salary is competitive and will be 
commensurate with experience. The Depart¬ 
ment’s facilities include SUN, NeXT, VAX, 
and IRIS graphics workstations, a SYM¬ 
BOLICS workstation, and an Intel hyper¬ 
cube all connected via Ethernet. Send an ap¬ 
plication, vita, and names and addresses of 
at least three references to: Computer Sci¬ 
ence Search Committee, Computer Science 
Department, University of Nevada, 4505 S. 
Maryland Parkway, Las Vegas, NV 89154. 
CSNET: datta@univ.edu. (702) 739-0870/ 
3681. Review of applications will begin 
February 15, 1990 and will continue until 
the positions are filled. Positions will be filled 
pending approval by the Vice President for 
Academic Affairs. UNLV is an EO/AA em¬ 
ployer. UNLV only employs U S. Citizens 
and aliens authorized to work in the U.S. 


NEW JERSEY INSTITUTE 
OF TECHNOLOGY 
Faculty Positions 

Computer & Information Science 

NJIT seeks assistant, associate and full 
professors for spring/fall 1990. Ph.D. in 
computer science or closely related field re¬ 
quired. Senior level applicants must have 
proven research and funding record. Posi¬ 
tions available in, but not limited to: distributed 
computing including computer architecture, 
operating systems, data communications 
and networking, realtime computing and 
fault tolerance; software development in¬ 
cluding compiling, computer graphics, office 
automation, data management systems, in¬ 
formation management systems, cognitive 
science, and computational linguistics. 
Department offers B.S., B.A., M.S., and 
Ph.D., in computer science. Computing 
facilities include VAX 8800, VAX 8530, 
IBM 4361, SUN workstations, Symbolics 
machines, TI Explorers and graphic systems. 

NJIT is the technological university of 
New Jersey with nearly 8,000 students 
enrolled in Newark College of Engineering, 
the School of Architecture, College of Sci¬ 
ence and Liberal Arts, and the School of In¬ 
dustrial Management. 

NJIT does not discriminate on the basis of 
sex, race, color, handicap, religion, national 
or ethnic origin, or age in employment. 

Send resume and name of at least three 
references to: Personnel Box CIS, New 
Jersey Institue of Technology, Newark, NJ 
07102. 


106 


COMPUTER 














UNIVERSITY OF CALIFORNIA 
AT DAVIS 
Faculty Positions in 
Computer Science 

The Computer Science Division of the 
Department of Electrical Engineering and 
Computer Science of the University of Cali¬ 
fornia at Davis invites applicants for tenure- 
track positions at all ranks, in areas of dis¬ 
tributed computing, theory, architecture, 
graphics, programming systems and 
languages. 

The division is in a period of rapid growth, 
with the aim of becoming one of the leading 
computer science programs in the nation. 
Programs are offered leading to the Bachelor 
of Science, Master of Science, and Doctor of 
Philosophy degrees. Constantly expanding 
research facilities include Sequent, Encore, 
and Intel multiprocessor systems, several 
VAX systems, and numerous Sun, Microvax 
II, Apollo, and Iris workstations, all linked via 
LAN. Also available are departmental and 
campus instruction facilities, and the super¬ 
computer resources of the Lawrence Liver¬ 
more National Laboratories. Salary and 
benefits are extremely attractive. 

The progressive city of Davis has a popu¬ 
lation of approximately 50,000. Located 
eleven miles from the state capital of Sacra¬ 
mento, it is an easy drive to the major 
cultural centers of the San Francisco Elay 
Area, as well as to unparalleled recreation 
areas, including the California coast and the 
Sierra Nevada mountains. The location, cli¬ 
mate, and character of Davis make it an out¬ 
standing living environment. 

Applicants should have a commitment to 
continued strong records of teaching and 
research, including the desire and ability to 
attract significant external support. A Ph.D. 
is required for all ranks. Advanced ranks re¬ 
quire experience and accomplishments 
commensurate with placement. The posi¬ 
tions are open until filled. 

Respond with a resume and the names of 
at least three references to: 

Robert M. Keller, Chair 

Division of Computer Science 

University of California at Davis 

Davis, CA 95616 

The University of California is an equal 
opportunity/affirmative action employer. 


WAKE FOREST UNIVERSITY 
Department of Mathematics and 
Computer Science 
Department of Radiology 
Assistant/Associate Professor of 
Computer Science and Radiology 

Applications are invited for a tenure-track 
joint position in the Department of Mathe¬ 
matics and Computer Science and the De¬ 
partment of Radiology. Candidates at the 
level of Assistant Professor or Associate Pro¬ 
fessor will be considered. A Ph.D. in com¬ 
puter science or equivalent is required. 

Primary research responsibilities should 
focus on applications of image analysis and 
image processing in Radiology. The ideal 

terest in medical image processing/analysis, 
parallel computations and high speed com¬ 
puting for imaging applications. Additional 
expertise in the areas of computer graphics, 


artificial intelligence, computer architecture 
and communications is desirable. A demon¬ 
strated ability to attract research funding is 
essential. 

Teaching responsibilities will include one 
undergraduate computer science course per 
semester. An undergraduate major in Com¬ 
puter Science is currently offered and a mas¬ 
ter’s degree in Computer Science is currently 
being developed in the Department of Math¬ 
ematics and Computer Science. A master’s 
and doctorate degree in Electrical and Com¬ 
puter Engineering with emphasis on medical 
applications is being offered through a re¬ 
search program sponsored jointly by the 
Bowman Gray School of Medicine and 
North Carolina State University with the de¬ 
gree awarded by N.C. State University. 

The image processing laboratory in the 
Department of Radiology supports a number 
of Sun 4 workstations, an AT&T 3B20, a 
stand-alone MRI workstation, an AT&T 
Pixel Machine and several terminals and 
PC’s. The workstations and the 3B20 are 
part of the state-wide extended Ethernet 
operated by the Microelectronics Center of 
North Carolina with access to Internet, Bitnet 
and other wide area networks. The lab is 
housed in the new MRI building which has 
two Picker 2T MRI scanners and a third GE 
unit is scheduled to be installed in the first 
quarter of 1990. Research time is available 
on the MRI units as well as on a fully in¬ 
tegrated clinical PACS. 

Available in the Department of Mathema¬ 
tics and Computer Science are SUN 4 work¬ 
stations and various microcomputers net¬ 
worked via Ethernet, the university’s Prime 
4150 and AT&T 3B15, and access to CSNet 
and LINCNET. Several parallel computing 
machines based on transputers will soon be 
available. Currently a plan is being im¬ 
plemented to connect the Reynolda Cam¬ 
pus of Wake Forest to the Bowman Gray 
Campus via the extended Ethernet operated 
by MCNC. 

Applications and inquiries should be sent 
to: Dr. Douglas Maynard, Chairman of 
Computer Science/Radiology Search Com¬ 
mittee, Department of Radiology, Bowman 
Gray School of Medicine, Wake Forest Uni¬ 
versity, Winston-Salem, North Carolina 
27103. 

EOAA employer. 


TRANSYLVANIA UNIVERSITY 

Computer Science: Assistant/Associate 
Professor, Transylvania University. Full¬ 
time, tenure track. Ph.D. in computer sci¬ 
ence or master’s in computer science with 
Ph.D. in a closely related field. Rank and 
salary dependent upon background. Excep¬ 
tionally well qualified candidates may be 
considered for a Bingham award for Excel¬ 
lence in Teaching. This recognition provides 
a supplement of up to 50% of base salary for 
the position. Transylvania is a private, liberal 
arts college with a strong commitment to ex¬ 
cellence in undergraduate education. The 
program in computer science is of long 
standing and is recognized for its outstanding 
quality. Please send letter of application, cur¬ 
riculum vitae, and names of three references 
to Dr. James E. Miller, Computer Science 
Program, Transylvania University, Lexing¬ 
ton, KY 40508. EOE 


NATIONAL CHIAO TUNG 
UNIVERSITY 

The Department of Computer & Informa¬ 
tion Science invites applications for Distin¬ 
guished Professors and faculty positions in 
August 1990. The Department offers B.S., 
M.S. and Ph.D. degrees. A candidate must 
have a Ph.D. in computer science, engineer¬ 
ing, or related field. 

Please send resume and names of three 
references to: Professor Kou-Yuan Fluang, 
Chairman, Department of Computer & In¬ 
formation Science, National Chiao Tung 
University, Hsinchu, Taiwan, R. O. C., 
Consideration of applications will begin in 
April 1990 and the search will remain open 
until the positions are filled. 


ARKANSAS STATE UNIVERSITY 
Faculty Position in Computer Science 

The Department of Computer Science, 
Mathematics and Physics invites applications 
for a tenure track position beginning August 
15, 1990. The department offers the B.S. 
and M.S. degrees in Computer Science. The 
Doctorate or ABD status in computer sci¬ 
ence is required. Preference will be given to 
applicants with an interest in teaching. Pro¬ 
vide a current resume, three current letters of 
reference, and transcripts (copies accept¬ 
able). Screening will begin March 1, 1990 
and continue until the position is filled. 
Submit applications to Dr. Robert F. Rossa, 
Chair of the Search Committee, P.O. Box 
70, State University, AR 72467. ASU is an 
Equal Opportunity/Affirmative Action 
employer. 


UNIVERSITY OF CINCINNATI 
OMI COLLEGE OF APPUED SCIENCE 
Math/Physics/Computer Technology 
Department Head 

The OMI College of Applied Science is a 
four-year engineering technology college of 
the University of Cincinnati. Current day and 
evening enrollment is 1600. The Math/ 
Physics/Computing Technology depart¬ 
ment head provides academic and admini¬ 
strative leadership for a seven member de¬ 
partment providing instruction for day and 
evening associate and baccalaureate degree 
programs. The primary academic courses in¬ 
clude: Collegiate Mathematics through In¬ 
tegral Calculus, Differential Equations, Ad¬ 
vanced Applied Mathematics, Linear Alge¬ 
bra, Vector Analysis, Probability and 
Statistics, College Physics and major com¬ 
puter applications for micro- and mini¬ 
computers and programming languages. 
Minimum qualifications: MS/MA in Math, 
Physics or Computer Science with back¬ 
ground in other two fields; evidence of ex¬ 
cellence in college-level teaching; demon¬ 
strated administrative ability. Availability: 
Tenure track appointment available Septem¬ 
ber 1, 1990. Nominations and applications, 
including three references, should be for¬ 
warded by March 23,1990 to: Jo Diamantes, 
Sr. Admin. Asst.; OMI College of Applied 
Science; 2220 Victory Parkway; Cincinnati, 
OH 45206-2822. 

Women and Minorities encouraged to 
apply. An AA/EEO employer. 
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UNIVERSITY OF PITTSBURGH 

Department of Computer Science 

The Department of Computer Science 
has entered a period of substantial growth 
and invites applications for several tenure 
track faculty positions at the assistant pro¬ 
fessor level to be filled by June, 1990 or as 
soon as possible. Responsibilities include 
research, supervision of graduate student 
research (Ph.D. and M.S.), and graduate 
and undergraduate teaching. Candidates 
should have a Ph.D. in computer science or 
in a closely related field and a strong interest 
in both research and teaching. Candidates 
should have specialized in programming lan¬ 
guages, operating systems, artificial in¬ 
telligence, or data base management. 

The Department currently has twenty- 
three full-time faculty members and supports 
strong graduate and undergraduate pro¬ 
grams. Departmental resources include an 
excellent research library and extensive com¬ 
puting facilities including a network of SUN 
and Xerox 1100-series (Dandelion) worksta¬ 
tions, a VAX 11/780 (under BSD UNIX), a 
variety of micro-computers, and several 
graphics systems. The research systems are 
accessible via the Department’s Ethernet- 
compatible LAN. Convenient access is also 
provided to the extensive general computer 
facilities of the University as well as to other 
networks (e.g., ARPANET, CSNET). The 
Department operates the Center for Parallel, 
Distributed and Intelligent Systems (CPDIS) 
to provide an environment for innovative re¬ 
search in computer science. Since the Uni¬ 
versity of Pittsburgh is a founding member of 
the Pittsburgh Supercomputing Center and 
an affiliate member of the Software Engi¬ 
neering Institute, the Department of Com¬ 
puter Science has access to the Cray 
X-MP/48 of PSC and the software engi¬ 
neering expertise at SEI. 

Please send your resume to: Dr. Alfs Berz- 
tiss, Chair of Faculty Search, Department of 
Computer Science, University of Pittsburgh, 
Pittsburgh, PA 15260. 

Pitt is an equal opportunity/affirmative ac¬ 
tion employer and especially encourages 
women and members of ethnic minorities to 
apply. 


ACADEMIA SINICA 
Taiwan, Republic of China 
Institute of Information Science 

Applications are invited for research posi¬ 
tion in Institute of Information Science, Aca¬ 
demia Sinica. Ph.D. in computer or closely 
related fields required. Demonstratable re¬ 
search ability necessary. Applicants for 
senior positions must have proven research 
record. AH fields in computer science are 
welcome. 

The Institute offers a good reseach en¬ 
vironment. No duty of teaching. Facilities in¬ 
clude 2 VAX’s, many SUN, IRIS, and E&S 
workstations, and an easily accessible ETA- 
10Q supercomputer at Academia Sinica. 
Budget for a parallel machine is available this 
year. 

Interested people please send application 
to Dr. Y.S. Kuo, Acting Director, Institute of 
Information Science, Academia Sinica, Tai¬ 
pei, Taiwan 11529, Republic of China. 
FAX: (011-886-2) 782-4814. 


DUKE UNIVERSITY 
Department of Computer Science 

Applications are invited for a tenure-track 
position at the rank of Assistant Professor, 
beginning September 1990. The search 
focuses on computer scientists who work in 
measurement and modeling for computer 
performance and dependability. Related 
areas of fault-tolerant computing, computer 
system architecture, VLSI Design/CAD, 
operating systems and computer networks 
are also welcome. 

The Department has major research ef¬ 
forts in computer systems with emphasis on 
modeling of fault-tolerant systems, systems 
performance, communications, and compu¬ 
ter architectures; scientific computing with 
emphasis on numerical linear algebra, the 
solution of PDEs, and VLSI simulation; ar¬ 
tificial intelligence, particularly in the areas of 
logic programming, naturallanguage inter¬ 
face, and search methodologies; and theory 
and algorithms with emphasis on parallel 
and randomized algorithms. Special motiva¬ 
tion for the research efforts comes from the 
areas of VLSI (in collaboration with the 
Microelectronics Center of North Carolina, 
of which Duke is a Participating Institution), 
and medical applications (in collaboration 
with the Duke Medical Center). 

Applicants should include a curriculum 
vitae, a list of publications, a few most impor¬ 
tant publications and a list of references. 
These should be sent by February 16, 1990 
to; 

Professor Kishor S. Trivedi or 
Professor Donald J. Rose, Chairman 
Department of Computer Science 
Duke University 
Durham, NC 27706 
Duke University is an affirmative action, 
equal opportunity employer. 


SWARTHMORE COLLEGE 
Computer Science Program 
Swarthmore, PA 19081 

Applications are invited for a two-year 
leave replacement position (subject to final 
administrative approval). Rank will depend 
upon the applicant’s education and experi¬ 
ence. Swarthmore College is a small, selec¬ 
tive, liberal arts college located in a suburb 10 
miles outside of Philadelphia. The computer 
science program offers concentrations, 
minors, and special majors in computer sci¬ 
ence at the undergraduate level. We have a 
CS laboratory of Sun workstations as well as 
access to the campus network of Macin¬ 
toshes, Vaxstations, MicroVaxes, and a 
Vax8810. Apollo’s are available in the Engi¬ 
neering department. Both a Sun and a Mac 
will be provided in the office of the successful 
applicant. The position entails teaching 2 
courses per semester plus some administra¬ 
tive duties. Applicants should be comfortable 
teaching strong undergraduate courses in at 
least two of the following areas: Algorithms 
and Data Structures, Programming Lan¬ 
guages, Theory of Computation, or Artifical 
Intelligence. A resume and three letters of 
reference should be sent to: Charles F. Kele- 
men at the above address. At least two of the 
letters should speak to the candidates teach¬ 
ing ability. Applications from women and 
members of minority groups are encouraged. 


U.S. NAVAL ACADEMY 
Tenure-Track Position 
Computer Science 

An earned Ph.D. in Computer Science or 
related field is required. The applicant must 
have an interest in both teaching and re¬ 
search in a very high quality, CSAB ac¬ 
credited, undergraduate program. Preferred 
areas of interest include operating systems, 
computer architecture, or networks. Appli¬ 
cants from all areas will be considered. Ad¬ 
dress inquiries to Chairman Computer Sci¬ 
ence Department, United States Naval 
Academy Annapolis, MD 21402. Deadline 
for receipt of applications is 01 April 1990. 
Applications will be considered until the posi¬ 
tion is filled. An Equal Opportunity/Affir¬ 
mative Action Employer. 


WORCESTER POLYTECHNIC 
INSTITUTE 

The Computer Science Department in¬ 
vites applications for a tenure track faculty 
position. We expect to make an appoint¬ 
ment at the Assistant Professor level in the 
area of computer systems, although out¬ 
standing candidates from other areas or at 
the Associate Professor level will be con¬ 
sidered. Candidates should have a Ph.D. in 
Computer Science and a strong interest in 
both research and teaching. 

Worcester Polytechnic Institute empha¬ 
sizes quality in the undergraduate learning 
experience and is committed to an innova¬ 
tive project-oriented teaching environment. 
The undergraduate computer science de¬ 
gree is accredited by the Computer Science 
Accreditation Board. A current goal of the 
Institute is to enhance our graduate program 
and improve research activities. The depart¬ 
ment seeks qualified candidates who will 
help us achieve these objectives. 

The Department has 12 full-time faculty 
and 170 undergraduates. Our M.S. and 
Ph.D. graduate programs have 50 full-time 
and 100 part-time students. The Depart¬ 
ment has active research groups in artificial 
intelligence, computer vision, data and 
knowledge bases, distributed systems, per¬ 
formance evaluation, and theory. WPI is 
located close to the center of the Massachu¬ 
setts computer industry and excellent oppor¬ 
tunities exist for cooperative research and 
consulting. Department equipment includes 
an Encore MultiMax, a network of Sun 
workstations, Xerox Lisp machines, and nu¬ 
merous PCs, interconnected by a campus¬ 
wide Ethernet. A new Information Science 
Building is almost completed, and we will 
move into our new facilities during the 
1989-90 academic year. 

The Institute is located in an attractive 
residential section of Worcester, a city of 
170,000 in central Massachusetts. The city 
has many colleges and a wide variety of cul¬ 
tural opportunities. The academic and cul¬ 
tural activities of Boston are nearby, as are 
numerous recreational opportunities. 

Please send a resume and the names of 
three references, at least one of whom can 
comment on your teaching skills, to Prof. 
Robert Kinicki, Department Head, Depart¬ 
ment of Computer Science, WPI, Worces¬ 
ter, MA 01609. WPI is an Equal Opportun¬ 
ity/Affirmative Action Employer. 
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UNIVERSITY OF CALIFORNIA 
AT RIVERSIDE 
Faculty Positions in 
Computer Science 

Applications and nominations are invited 
for tenured or tenure track positions in Com¬ 
puter Science beginning July 1, 1990 or 
later. Ph.D. and demonstrated excellence in 
research and teaching are required. Promi¬ 
nent senior candidates are especially en¬ 
couraged to apply. The program in com¬ 
puter science is growing rapidly, and is pro¬ 
jected to double in size in the next 4 years. 
The department has decided to concentrate 
in areas projected to be important in the 21st 
century, including algorithm design, parallel 
computation, computational logic, design 
automation, programming languages, com¬ 
puter architecture, and software engineer¬ 
ing. Three open rank positions are available. 
One is targeted to Computational Logic and 
another is targeted to Design Technology; 
the third is open as to area. This is an oppor¬ 
tunity to participate in shaping a developing 
program in computer science, with the ad¬ 
vantage of a close liaison with a well- 
established mathematics department. 

Riverside is a rapidly growing community 
of over 200,000, one hour from Los 
Angeles; an independent metropolitan 
center, not a suburb. The city has its own 
Philharmonic and Civic Light Opera. Skiing 
is available from November to April less than 
1 hour away in the San Bernardino moun¬ 
tains. Housing is far less expensive than in 
most other areas of Southern California. The 
Riverside campus of the University of Cali¬ 
fornia has an undergraduate enrollment of 
6700 and a graduate enrollment of 1400, 
and is expected to double in size by the turn 
of the century. Other major institutions, such 
as UC Irvine, UCLA, USC, UC San Diego, 
and Cal Tech, are within easy driving 
distance. 

Send all materials including curriculum 
vita and the names of at least three refer¬ 
ences to: Professor Lawrence Larmore, 
Chairman, Computer Science Recruiting 
Committee, Department of Mathematics 
and Computer Science, University of Cali¬ 
fornia, Riverside, CA 92521. The pool of 
candidates will consist of all those whose 
completed applications are received by Jan¬ 
uary 8, 1990. If the search is not successfully 
completed from this pool, the pool will be 
enlarged to include all those whose com¬ 
pleted applications are received between 
January 9, 1990 and March 5, 1990. 

University of California, Riverside, is an 
Affirmative Action/Equal Opportunity 
Employer. 


RENSSELAER POLYTECHNIC 
INSTITUTE 
Faculty Positions 

Department of Electrical, Computer 
and Systems Engineering 

Rensselaer Polytechnic Institute, Depart¬ 
ment of Electrical, Computer, and Systems 
Engineering, invites applications for tenure- 
track faculty positions at all levels. Specific 
areas of interest include: (1) computer engi¬ 
neering, architecture, and performance 
evaluation; (2) computer and communica¬ 
tions networks, architectures and protocols. 


Senior faculty applicants with an interest in 
undertaking a leadership role in these re¬ 
search programs are encouraged. The ECSE 
Department is the largest academic unit at 
Rensselaer and has a rich tradition of re¬ 
search and education. The department is 
seeking to add faculty who bring an innova¬ 
tive approach to research and teaching. 
Active programs in computer engineering, 
solid-state electronics and integrated circuit 
design, control systems, robotics and 
automation, information and decision sys¬ 
tems, communications and signal process¬ 
ing, electronics and circuits, and fusion 
plasma systems contribute to a dynamic re¬ 
search environment. In addition to the ex¬ 
tensive research facilities of the department, 
there are opportunities to initiate or par¬ 
ticipate in interdisciplinary research pro¬ 
grams in one of the major research centers of 
the School of Engineering, including the 
Center for Integrated Electronics, the Rens¬ 
selaer Design Research Center, the Center 
for Manufacturing Productivity and Technol¬ 
ogy Transfer, and the NASA Center for In¬ 
telligent Robotic Systems in Space Explora¬ 
tion. New faculty are eligible for special ar¬ 
rangements including summer support, 
equipment, graduate student support, and 
reduced teaching load in order to encourage 
growth of their research programs. Applica¬ 
tions or requests for more information 
should be directed to: 

Dr. Arthur C. Sanderson, Chairman 
Electrical, Computer, and Systems 
Engineering Department 
Rensselaer Polytechnic Institute 
Troy, NY 12180-3590 
RPI is an affirmative action/equal oppor¬ 
tunity employer. 


RUTGERS UNIVERSITY 

The Department of Computer Science at 
Rutgers, The State University of New Jersey, 
invites applications for tenure-track faculty 
positions at both the junior and senior levels. 
Particularly sought are individuals pursuing 
research in Systems and Artificial Intelli¬ 
gence, although candidates in other areas 
will also be considered. 

The department has a mature graduate 
program, with an excellent pool of almost 
300 MS and PhD students, in addition to an 
undergraduate program leading to a Bache¬ 
lor’s degree. There are over 30 full time 
faculty members, with major strength in 
areas such as Algorithms and Theoretical 
Computer Science, Artificial Intelligence, 
Combinatorial Optimization, Numerical 
Analysis Database and Software Systems. 
Located in the New York City-Philadelphia 
corridor, Rutgers offers excellent opportu¬ 
nities for cultural activities and close profes¬ 
sional contact with nearby major research 
laboratories and other leading universities. 

An applicant should have a Ph.D. or ex¬ 
pect it within a short time, and should be 
committed to excellence in research and 
teaching. Send curriculum vitae, including 
the names and addresses of three refer¬ 
ences, and copies of recent papers to Prof. I. 
Rabinowitz, Chair of Faculty Search Com¬ 
mittee, Department of Computer Science, 
Hill Center, Rutgers University, New Bruns¬ 
wick, NJ 08903. Rutgers is an Affirmative 
Action/Equal Opportunity Employer. 


COLOR\DO STATE UNIVERSITY 

The Computer Science Department solic¬ 
its applications for tenure-track and visiting 
faculty positions at all levels (subject to fund¬ 
ing) . Candidates for assistant professor need 
a Ph.D. in computer science or computer 
engineering (at time of appointment) with 
promise for excellence in research and 
teaching; applicants for senior ranks must 
possess distinguished research records. The 
Department has approval for significant 
growth over the next few years, and has 
identified selected areas in parallel com¬ 
puting, artificial intelligence, and software 
engineering for special attention. In addition, 
at least one graphics specialist is sought. 
Salary is commensurate with rank and ex¬ 
perience. New and visiting faculty will enjoy 
duties especially conducive to productive 
research. 

The Department offers BS, MS, and PhD 
degrees. We have excellent cooperative re¬ 
search relations with industrial and govern¬ 
ment laboratories, and their people form a 
significant portion of our graduate student 
population. We operate numerous multi¬ 
user systems (HP, DEC, Sequent, ATT) and 
many workstations (Sun, Apple, ATT), all 
networked. University operations include a 
CYBER 205 vector supercomputer. Depart¬ 
ment personnel work in a pleasant, smoke- 
free environment. 

Fort Collins is a growing community of 
92,000 located along the foothills of the 
Rocky Mountains, 60 miles north of Denver. 
The climate is moderate—about 15 inches of 
precipitation and 290 days of sunshine per 
year. There are many cultural opportunities 
and year-round outdoor activities. 

Send your curriculum vitae and names of 
at least three professional references to: Dr. 
R.R. Oldehoeft, Search Committee, Com¬ 
puter Science Department, Colorado State 
University, Fort Collins, CO 80523. Ap¬ 
plications for August, 1990 will be con¬ 
sidered March 1, 1990. The search may be 
extended if suitable candidates are not 

Colorado State University is an EEO/AA 
Employer. EO Office: 314 Student Services 
Building. 


GRAND VALLEY STATE UNIVERSITY 
Allendale, Michigan 

Applicants invited for tenure track posi¬ 
tions beginning Fall, 1990. Candidates must 
have Ph.D. in Computer Science or Infor¬ 
mation Systems, with an interest in teaching 
at the graduate and undergraduate levels. 

The department offers undergraduate 
majors in Computer Science and Informa¬ 
tion Systems, with masters degrees in Com¬ 
puter Information Systems and Software 
Engineering. 

GVSU is located just west of Grand 
Rapids, the second largest metropolitan area 
in Michigan, offering numerous cultural and 
recreational opportunities. Cost of living is 
moderate and quality of life is high. 

Send resume to: Computer Science 
Search Committee, Math & CS Dept., 
Grand Valley State University, Allendale, MI 
49401. 

Consideration of applications will con¬ 
tinue until position is filled. AA/EEO 
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CLARKSON UNIVERSITY 
Electrical and Computer 
Engineering Department 

Applications are invited for tenure-track 
faculty positions at the Assistant/Associate/ 
Full Professor level. Openings exist in the 
computer engineering area as well as in solid 
state, power systems, and communications 
systems. A doctorate is required. Review of 
applications will begin February 28, and will 
continue until the positions are filled. Re¬ 
sponsibilities include undergraduate and 
graduate teaching and development of a 
research program. 

The department offers programs at the 
B.S., M.S., and Ph.D. levels. Last year 215 
bachelors, 11 masters, and 10 doctorates 
were awarded, and research funding reached 
the level of $1.3 million dollars. Principle 
research areas include distributed and 
parallel computation, artificial intelligence, 
image and signal processing, robotics and 
control, power engineering, solid state 
devices, electromagnetic scattering, and 
communication theory. There are research 
laboratories in AI and neural computing, 
VLSI design, lasers and optics, solid state 
device fabrication, high voltage engineering, 
and dielectric breakdown. There are ex¬ 
cellent computer facilities throughout the 
university, and Clarkson was the first univer¬ 
sity to require all of its freshmen to have a 
personal computer. 

Clarkson is an independent college spe¬ 
cializing in engineering, science and man¬ 
agement with an undergraduate enrollment 
of 3200 students and a graduate enrollment 
of 400 students. Located in Northern New 
York, Clarkson is midway between the St. 
Lawrence River and the Adirondack Moun¬ 
tains and a two hour drive from both Ottawa 
and Montreal. Send applications to Profes¬ 
sor Henry Domingos, Acting Chairman, 
Department of Electrical and Computer 
Engineering, Clarkson University, Potsdam, 
NY 13699. Clarkson is an Equal Opportun¬ 
ity/ Affirmative Action Employer. 


MICHIGAN STATE UNIVERSITY 

Department of Computer Science 

The Department of Computer Science in¬ 
vites applications for a tenure track position 
at all levels. Candidates from all areas of 
specialization in computer science or com¬ 
puter engineering will be considered. How¬ 
ever, the Department has a special interest in 
candidates in the areas of software engineer¬ 
ing, programming languages, parallel pro¬ 
cessing and graphics. Candidates should 
have a Ph.D. in computer science or com¬ 
puter engineering and have a strong interest 
in both research and teaching. Rank and 
salary will be commensurate with qualifica¬ 
tions. The appointment is anticipated to 
begin in September 1990. The deadline for 
applications is March 1, 1990. However, ap¬ 
plications will be accepted until the position is 
filled. 

As a unit within the College of Engineering 
at Michigan State University, Computer Sci¬ 
ence offers the Bachelor of Science, Master 
of Science and Doctor of Philosphy degrees. 


Special support is available from within the 
college and university to initiate research by 
new faculty members. Faculty offices are 
connected to the MSUnet which provides 
access to an array of campus computing re¬ 
sources including the facilities of the College 
of Engineering, the Department’s VAX 8600, 
64-node NCUBE, 96-node BBN Butterfly, 
Pattern Recognition and Image Processing 
Laboratory and the Artificial Intelligence/ 
Knowledge Based Systems Laboratory Ac¬ 
cess to select off-campus computers is 
available, including the Advanced Com¬ 
puting Research Facility, at Argonne Na¬ 
tional Laboratory, the Pittsburgh Supercom¬ 
puter Center and the National Center for 
Supercomputing Applications at the Univer¬ 
sity of Illinois, as well as access to AR¬ 
PANET, CICNET, and CSNET. Additional 
facilities available to faculty include an IBM 
3090/180E vector processor, a dual-pro¬ 
cessor Convex, the College’s A.H. Case 
Center for Computer-Aided Engineering 
and Manufacturing, and the Electronics 
Research and Development Laboratory. 

Michigan State University enjoys a park¬ 
like campus of 2,100 developed acres and 
3,100 acres of experimental farms, outlying 
research facilities and natural areas. The 
campus is adjacent to the cities of East Lan¬ 
sing and the capital city, Lansing. The 
Greater Lansing area has approximately 
250,000 residents. The communities have 
fine school systems and place a high value 
on education. 

Applicants should send a resume, a state¬ 
ment of research and teaching interests, and 
the names and addresses of at least three 
references to: 

Dr. Anthony S. Wojcik, Chairperson 
Department of Computer Science 
A714 Wells Hall 
Michigan State University 
East Lansing, Michigan 48824-1027 
CSNET: wojcik@cpswh.cps.msu.edu 
Michigan State University is an Equal Op¬ 
portunity/Affirmative Action Institution and 
encourages applications from women and 
minorities. 


RESEARCH SCIENTIST 

Formulate models of integrated engineer¬ 
ing design systems to resolve computerized 
modeling problems with application in log¬ 
ging tool design and computer-aided engi¬ 
neering. Consult with engineers, study sys¬ 
tem proposals, and apply knowledge of 
engineering, artificial intelligence, and num¬ 
erical simulation as well as programming 
languages to implement automatic gener¬ 
ation of modeling and graphics codes into 
new knowledge-based systems. 

Requirements: M.S. in Mechanical or 
Electrical Engineering or in Computer Sci¬ 
ence . Must have 3 years experience in job of¬ 
fered or 4 years as Computer Applications 
Engineer, Electric Logging Tool Design, in¬ 
cluding one year of experience with artificial 
intelligence methods. Salary : $4,983/month 
for 40 hrs./wk. Apply at the Texas Employ¬ 
ment Commission, Austin, Texas, or send 
resume to Texas Employment Commission, 
TEC Building, Austin, Texas 78778. J.O. 
*5458103. Ad paid by an equal employment 
opportunity employer. 


SYRACUSE UNIVERSITY 
Faculty Positions 

The School of Computer and Information 
Science at Syracuse University invites appli¬ 
cations for faculty positions in all areas of 
computer science. Positions are currently 
budgeted at the assistant professor level. 
Outstanding candidates at higher levels will 
also be considered. Candidates for assistant 
professorships should be capable of research 
that extends the frontiers of the discipline. A 
Ph.D. or equivalent in Computer Science or 
a related area is required. Candidates for 
senior positions should be leaders in their 
fields with outstanding research records. All 
candidates are expected to pursue an active 
research program and must be committed to 
excellence in teaching. The School has par¬ 
ticular strength in parallelism, logic program¬ 
ming and coding theory. A variety of parallel 
computers is available to the faculty. The 
School has a 48-transputer computing sur¬ 
face. The Northeast Parallel Architectures 
Center at Syracuse University has Connec¬ 
tion Machines, Encore Multimax and Alliant 
computers. Applicants should send a re¬ 
sume, three references, and copies of se¬ 
lected publications (if any) by February 15, 
1990 to: Professor Per Brinch Hansen, 
Chair, Search Committee, School of Com¬ 
puter and Information Science, Center for 
Science and Technology, 4-116, SYRA¬ 
CUSE UNIVERSITY, Syracuse, NY 13244- 
4100. AA/EOE. 


SUNY COLLEGE AT PLATTSBURGH 

Department of Computer Science 

Two Visiting positions in Computer Sci¬ 
ence effective September 1, 1990 with pos¬ 
sibility of renewal. Plattsburgh State has a 
strong undergraduate program in Computer 
Science within a Liberal Arts setting. The BS 
Program in Software systems has been ac¬ 
credited by the Computer Science Accredi¬ 
tation Commission of the Computing Sci¬ 
ences Accreditation Board, Inc. 

Departmental interests include real-time 
software, artificial intelligence, natural lan¬ 
guage processing, computational science 
and parallel distributed processing. Platts¬ 
burgh State has a strong undergraduate pro¬ 
gram in Computer Science within a Liberal 
Arts setting. 

Ph.D. in Computer Science or related dis¬ 
cipline preferred; equivalent experience con¬ 
sidered; all specialties considered. 

Plattsburgh is located in the northeast cor¬ 
ner of New York State on the western shore 
of Lake Champlain, near the Adirondack 
Mountains and approximately sixty miles 
from Montreal. 

Deadline for initial screening of applica¬ 
tions is February 26, 1990. Applications will 
be accepted until positions are filled. Send 
letter of application and three letters of 
recommendation to: 

Chair, Search Committee 
c/o Office of Personnel/Affirmative Action 
SUNY Plattsburgh 
Box 1654-1001 
Plattsburgh, New York 12901 

SUNY Plattsburgh is an Equal Opportuni¬ 
ty Employer. Individuals with an under¬ 
standing of and sensitivity to minority and 
gender concerns are encouraged to apply. 
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TRINITY COLLEGE 
Computer Science Faculty 

Trinity College is establishing a Depart¬ 
ment of Computer Science and is seeking 
candidates at any level for a tenure track 
position starting in August 1990. The success¬ 
ful candidate will join two other computer 
science faculty in the continued develop¬ 
ment of the computer science major which 
was begun in 1985 and is presently offered 
through the Department of Engineering and 
Computer Science. 

Candidates must have a Computer Sci¬ 
ence Ph.D., a strong commitment to excel¬ 
lence in undergraduate teaching, a willing¬ 
ness and ability to participate in the continued 
development of a strong liberal arts com¬ 
puter science major and the potential to pur¬ 
sue an active research program. Applicants 
in all areas of computer science will be 
considered. 

Trinity College is a selective liberal arts 
college with a strong commitment to the sci¬ 
ences. In addition to computer science, the 
College offers majors in engineering, mathe¬ 
matics, chemistry, biochemistry, physics, bi¬ 
ology and psychobiology. The College’s aca¬ 
demic computing facilities include a VAX 
8350, a network of Sun 3/50 and 3/60 
workstations and numerous personal com¬ 
puters. Trinity College is an equal opportuni¬ 
ty/affirmative action employer, and has a 
primary goal of increasing the number of 
women and minority faculty in the sciences. 
Please send application letter, vita and letters 
of reference to Professor Ralph Walde, 
Department of Engineering and Computer 
Science, Trinity College, Hartford, CT 
06106. Consideration of applications will 
begin immediately and the search will remain 
open until the position is filled. 


UNIVERSITY OF NORTH CAROLINA 
AT CHARLOTTE 

The Electrical Engineering Department at 
the University of North Carolina at Charlotte 
invites applications for tenure-track positions 
at the Assistant, Associate or Full Professor 
level in digital system design, signal and im¬ 
age processing/communications, control 
systems, semiconductor materials science, 
device physics, and IC process technology. 
The University of North Carolina at Char¬ 
lotte is one of the largest institutions of the 
UNC system. It has over 13,000 students, 
including 1,940 graduate students in the six 
colleges. The department is one of five in the 
College of Engineering with 350 students, of 
which 30 are graduate students and Post¬ 
doctoral Research Associates. Computer 
facilities include micros, minis, workstations 
and free access to Cray YMP supercomputer 
via microwave links. The laboratory facilities 
include a class 100 clean room with com¬ 
plete integrated circuit and microstructure 
fabrication capabilities, laboratories for 
measuring the electrical properties of the 
insulator-semiconductor system, IC compu¬ 
terized test facilities, laser-electrooptic 
laboratory, new plasma processing labora¬ 
tory for VLSI fabrication, and new MBE 
laboratory for quantum well superlattice and 
optoelectronic materials. As a participating 
institution in the Microelectronics Center of 
North Carolina the faculty have access to the 


MCNC facilities with capability of submicron 
IC design, fabrication test and semiconduc¬ 
tor materials analysis. Charlotte is the largest 
city in the Carolinas and offers good schools 
and attractive housing. The 100,000 sq. ft. 
engineering building is located adjacent to 
the 3,500 acre University Research Park. 
A new 75,000 sq. ft. applied research build¬ 
ing will soon be completed. Various forms of 
career development support are available. 
Applicants should have a Ph.D. degree and 
have commitment to teaching and pursuing 
research. Industrial and research experience 
is desirable. Rank and salary commensurate 
with experience. Applications will be ac¬ 
cepted until March 1, 1990. Initial screening 
begins February 1, 1990. Applications in¬ 
cluding a resume and four references should 
be sent to Dr. Y.P. Kakad, Chairman, Search 
Committee, EE Dept., UNC-Charlotte, Char¬ 
lotte, NC 28223. UNC-Charlotte is an equal 
opportunity affirmative action employer, 
and complies fully with the immigration Re¬ 
form and Control Act of 1986. 


UNIVERSITY OF 

MARYLAND UNIVERSITY COLLEGE 
Faculty for Europe and Asia 

Planning a sabbatical or leave of absence? 
The University of Maryland University Col¬ 
lege seeks excellent lecturers for under¬ 
graduate computer science, computer appli¬ 
cations, and information systems manage¬ 
ment courses on U.S. military bases in 
Europe and in Asia and the Pacific. Renew¬ 
able annual appointments begin August 
1990. Minimum requirements include a 
master’s degree in computer science or a 
related field, recent college teaching ex¬ 
perience, and U.S. citizenship. Benefits in¬ 
clude transportation and military base privi¬ 
leges. Frequent travel and the cost of school¬ 
ing make these positions difficult for those 
with children. Send resume to Dr. Ralph E. 
Millis, Overseas Programs, The University of 
Maryland University College, College Park, 
MD 20742-1642. AA/EEO. 


VIENNA UNIVERSITY OF 
TECHNOLOGY 
AUSTRIA 

The Technisch-Naturwissenschaftliche 
Fakultaet at the Vienna University of Tech¬ 
nology invites applications for a new chaired 
professorship in computer science. This new 
chair should cover the field of Software tech¬ 
nology in theory and practice, teaching and 
research. The applicant is also expected to 
give one basic course in computer science. 
Requirements are a corresponding Austrian 
or foreign university degree, and a venia 
docendi on an Austrian or foreign university, 
or an equivalent scientific qualification. 
Austrian citizenship is not required. A rea¬ 
sonable command of the German language 
is expected. Applicants should send a com¬ 
plete resume, a copy of the three most im¬ 
portant papers/projects to: 

Dekanat der Technisch-Naturwissensch- 
aftlichen Fakuitaet, University of Technol¬ 
ogy, Getreidemarkt9, A-1060 Vienna, Aus¬ 
tria. Deadline is March 31, 1990. 


McGill university 

Computer Engineering 

The establishment of a new degree pro¬ 
gram in Computer Engineering has created a 
number of tenure-track faculty openings in 
the Department of Electrical Engineering at 
McGill University. These can be at any level 
of rank and will be effective September 1st, 
1990. Applications are invited from in¬ 
dividuals who are. dedicated to teaching at 
both the undergraduate and graduate levels, 
and who have outstanding research poten¬ 
tial and demonstrated research ability in any 
of the following areas: Software Engineer¬ 
ing, Computer Architecture, Operating Sys¬ 
tems, Computer Systems Engineering, Par¬ 
allel Computing, and Distributed Systems. 

The Department has a faculty of 29 pro¬ 
fessors and a student body of approximately 
600 undergraduate majors and 230 gradu¬ 
ate students, 70 of whom are Doctoral can¬ 
didates. Research areas in which the Depart¬ 
ment has strong groups with an international 
reputation include Computer Vision (part of 
the McGill Research Center for Intelligent 
Machines), Computational Analysis and De¬ 
sign Automation, Communications Systems, 
Systems and Control, and VLSI Design and 
Test. The School of Computer Science, with 
its strengths in algorithms, computational 
geometry, numerical analysis, architecture 
and networks, provides another major 
forum for interaction. 

Candidates must hold an earned Ph.D. 
degree. In addition, a bachelor’s degree from 
an accredited engineering school would be 
an asset. Please send a resume and a list of 3 
references to: 

Professor V.K. Agarwal 
Chairman, 

Computer Engineering Search Committee 
Department of Electrical Engineering 
McGill University 

3480 University Street 
Montreal, Quebec 
Canada H3A 2A7 
Tel: (514) 398-7136 

In accordance with Canadian Immigration 
requirements, this advertisement is directed 
in the first instance to Canadian citizens and 
Permanent residents of Canada. Applica¬ 
tions from others are welcomed, however, 
consideration of such candidates must be 
deferred until a Canadian search has been 
completed. 


SOFTWARE ENGINEER 

Youngstown, Ohio area Duties: Support 
of Burroughs Network Architecture Version 
2; support of communications management 
system; support of master control program; 
support of a system for recovery of network 
message switching using data communica¬ 
tions algo and interface to the data base 
management system version II. Salary: 
$39,000.00 per annum - 40 hours a week 
from 9 AM to 5 PM. Requirements: B.S. 
with two years of experience in the job 
described. Send resume (No calls) to: R. 
Lechler, JO* 1190520, Ohio Bureau of 
Employment Services, P.O. Box 1618, Co¬ 
lumbus, Ohio 43216. 
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LAMAR UNIVERSITY 
Computer Science 
Department Faculty Positions 

The Computer Science Department at 
Lamar University has two tenure-track 
Assistant/Associate Professor positions 
available beginning in the Spring 1990 
semester. 

Our program has 350 undergraduate 
C.S. majors, and 55 graduates. There are, 
at present, eight full-time and five part-time 
faculty members in the department, with in¬ 
terests ranging from Artificial Intelligence to 
Operating Systems. 

Lamar is currently installing a clustered 
VAX network, while carefully considering 
the possible directions Computer Science 
might take during the next five years. We 
think our relatively young program offers an 
excellent opportunity for a young graduate. 

For individuals who are outdoor oriented, 
Beaumont is an ideal location. It is within 30 
minutes of salt/fresh water fishing, sailing, 
the Big Thicket National Forrest Reserve, 
Sea Rim State Park, and 3 public golf 
courses. Both Houston and Galveston are 
within l'/2 hours from the greater Beaumont 
area. Beaumont has a fine symphony or¬ 
chestra. Housing costs are relatively low and 
the region is conducive to family living. 

Lamar is a middle-state university with a 
student population of 15,000. The Com¬ 
puter Science Department is housed within 
the College of Engineering. Degrees offered 
by the department include a B.S. in Com¬ 
puter Science, a B.S. in Computer and In¬ 
formation Systems, a B.S. with a double 
major in Electrical Engineering Computer 
Science, and an M.S. in Computer Science. 

Applicants should respond to Dr. Ronald 
King, Computer Science Department, 
Lamar University, P.O. Box 10056, Beau¬ 
mont, TX 77710, (409) 880-8775. 


UNIVERSITY OF WASHINGTON 

The Department of Computer Science 
and Engineering expects to have one or 
more tenure-track openings starting in the 
1990-91 academic year. We seek outstand¬ 
ing applicants who add to our existing re¬ 
search strengths, particularly in graphics, 
programming languages/compilers, and 
software engineering, or who bring signifi¬ 
cant new research strength to our department. 

A moderate teaching load allows time for 
quality research and close involvement with 
students. We expect applicants to have a 
strong commitment to both research and 
teaching, and an outstanding record of 
research for their level. 

The department may also have several 
visiting positions that would require both 
teaching and research. It may be possible to 
hold these for portions of the 1990-91 aca¬ 
demic year. 

Interested applicants should send a letter 
of application, a resume, and the names of 
four references to Paul Young, Faculty Re¬ 
cruiting Committee, Department of Com¬ 
puter Science and Engineering FR-35, Uni¬ 
versity of Washington, Seattle, Washington 
98195. 

The University of Washington is an Affir¬ 
mative Action/Equal Opportunity Employer. 
The Ph.D. is required for these positions. 


BOSTON UNIVERSITY 
Software Engineering Faculty Positions 

The Department of Electrical, Computer 
and Systems Engineering at Boston University 
seeks applications for two faculty positions in 
the area of Software Engineering, with ap¬ 
pointments starting in the fall of 1990. One 
position is at the Associate/Full Professor level 
for candidates specializing in embedded com¬ 
puter systems for real-time applications. The 
second position is at the Assistant/Associate 
Professor level for candidates with a back¬ 
ground in data communications and software 
design for distributed systems. Candidates for 
these positions must have earned doctorates 
and education or experience in a relevant 
field. They should be interested in teaching 
and developing a program of sponsored 
research. 

With strong industrial support from industry 
in the Routes 128 and 495 area surrounding 
Boston, the Department is committed to 
building a software engineering program of 
national prominence. In 1987, the faculty of 
the College approved a forward looking 
Master’s Degree program which focuses on 
the design of software for real-time embedded 
systems and distributed systems. This new 
program also incorporates key elements of the 
software engineering program of the Wang In¬ 
stitute, which merged with Boston University 
in 1986. A major laboratory, consisting of 20 
workstations and advanced CASE software, 
is in place in the new engineering building to 
support the teaching of embedded systems 
design. A second laboratory for human inter¬ 
face design will be installed in 1990, and a 
third laboratory for computer communications 
software design is planned. 

Boston University is located in the heart of 
the Boston academic community along the 
Charles River, with easy access to the out¬ 
standing scientific, cultural and tourist attrac¬ 
tions of the city. The Department of Electrical, 
Computer and Systems Engineering has 34 
faculty, and approximately 50 PhD, 250 MSc 
and 700 BSc majors. Opportunities exist for 
collaboration with colleagues in other Boston 
area universities, as well as with the leading 
computer and software companies in the 

Applicants should send their curriculum 

Professor Thomas G. Kincaid, Chairman 

Department of Electrical, Computer and 
Systems Engineering 

College of Engineering 

Boston University, Boston, MA 02215 

Boston University is an Equal Oppor¬ 
tunity/ Affirmative Action Employer. 


ENGINEER 

Computer (Software) - Will accept entry 
level with BS degree either computer, elec¬ 
trical or mathematics or related field with 
heavy college computer course background. 
Will assist in design and implementation of 
enhancements to a DOS-based TCP/IP, 
design and implementation to network ap¬ 
plications that interact to TCP/IP and 
analysis of network communications to 
determine source of problems and enhance 
performance. Salary $39,000 year. 

Send resume to: Locus Computing 
Corp., 9800 La Cienega Blvd., Inglewood, 
CA 90301; Att: Mr. Kirby Sechovec. 


NAVAL POSTGRADUATE SCHOOL 

The Computer Science Department invites 
applications for faculty positions at all levels. 
Our primary interests are in the areas of 
operating systems and programming lan¬ 
guages. Our secondary interests are in the 
areas of visual data processing, graphics, 
and computer architecture (especially real¬ 
time and parallel-processing aspects of the 
three). Applicants should have a Ph.D. in 
Computer Science or a closely related field 
and be committed to high-quality teaching 
and research. Senior applicants must have 
distinguished research records. Appoint¬ 
ments can begin at any time. 

The Department offers M.S. and Ph.D. 
degrees in computer science, but no under¬ 
graduate degrees. Currently, 110 students 
are enrolled in the M.S. program and five in 
the Ph.D. program. Students are military of¬ 
ficers or civilian employees of the Depart¬ 
ment of Defense and are fully supported by 
their sponsoring organization during their 
studies. Departmental facilities (supported 
by eight full-time computer professionals) in¬ 
clude six instructional and research labora¬ 
tories with extensive state-of-the-art equip¬ 
ment. Faculty normally teach for two quarters 
and perform research for two quarters per 
year. The Monterey-Carmel area provides a 
pleasant coastal climate and easy access to 
Silicon Valley companies. 

Send a detailed resume, an abstract of 
your best recent research, and letters of ref¬ 
erence to: 

Faculty Search Committee 
Computer Science Department, Code 52 
Naval Postgraduate School 
Monterey, CA 93943 
Telephone (408) 646-2449 
An Equal Opportunity/Affirmative Action 
Employer 


WESTERN CONNECTICUT STATE 
UNIVERSITY 

DANBURY, CONNECTICUT 
Computer Science 

Applications are invited for two tenure- 
track positions in Computer Science for the 
fall of 1990. Rank and salary commensurate 
with experience. Salaries are highly com¬ 
petitive. 

The areas of prime interest are: operating 
systems, compiler design, telecommunica¬ 
tions, graphics, and database. 

Applicants should have a Ph.D. in Com¬ 
puter Science or a related field. 

Applicants should demonstrate a strong 
commitment to teaching at the undergradu¬ 
ate and the beginning graduate level. 

The University is located in a dynamic 
area within 60 miles of New York City, New 
Haven, and Hartford. Many professional 
and cultural opportunities exist. 

Deadline for applications is March 15, 
1990 or until suitable candidates are se¬ 
lected. Send a letter of application, resume, 
and the names of three references to: 

Richard M. Jones, Assoc. Chair. 

Department of Math, and Computer 
Science 

Western Connecticut State University 

Danbury, CT 06810 

An Equal Opportunity/Affirmative Action 
Employer. 


12 


COMPUTER 








UNIVERSITY OF MIAMI 
CORAL GABLES, FLORIDA 

The Department of Electrical and Com¬ 
puter Engineering invites applications for a 
tenure-track faculty position in Computer 
Science/Engineering at the Assistant/Asso¬ 
ciate Professor level. Preferred areas of in¬ 
terests are operating systems, programming 
languages, software engineering, and data¬ 
base. Qualifications include an earned doc¬ 
torate and potential for quality research and 
teaching. Salary will be commensurate with 
rank and experience. The University is 
located in Coral Gables, a suburb of Miami, 
FL. Applications should be sent with the 
names of three references to: Dr. Tzay Y. 
Young, Acting Chair, Department of Elec¬ 
trical and Computer Engineering, P.O. Box 
248294, University of Miami, Coral Gables, 
Florida 33124. The University of Miami is an 
equal opportunity/affirmative action 
employer. 


POLYTECHNIC UNIVERSITY 
Head, Department of 
Computer Science 

The Department of Computer Science of 
the School of Electrical Engineering and 
Computer Science invites applications for 
the position of Head of Computer Science. 

Polytechnic University is a technological 
urban university established in 1854 and is 
located on three campuses in the greater 
New York area. The main campus is in 
Downtown Brooklyn adjacent to Brooklyn 
Heights, one of New York’s desirable resi¬ 
dential communities. The other two cam¬ 
puses are in Farmingdale, Long Island, and 
in Hawthorne, Westchester County. The 
Brooklyn campus is undergoing major de¬ 
velopment involving Metrotech, a 16-acre 
academic/research/industrial park. The 
university has an enrollment of approximate¬ 
ly 4,700 students. Because of its location, 
there is close interaction with major compan¬ 
ies in New York and New Jersey. 

The Department of Computer Science of¬ 
fers degree programs leading to the BS, MS 
and Ph.D. degrees. There are 18 tenure- 
track faculty members in the Department of 
Computer Science. Active research is being 
carried out in the areas of software engineer¬ 
ing, algorithms, programming languages, 
compilers, computer architecture, network 
analysis and management, and image analy¬ 
sis and understanding. The undergraduate 
program is accredited by CSAB. In 1989 
there were 158 MS degrees and 7 Ph.D. de¬ 
grees awarded in Computer Science. Com¬ 
puter facilities include Sun workstations, 
Apollo Workstations, a VAX 780, an IBM 
4381, an IBM 4341, a Gould 6000, an 
AT&T 3B15, two AT&T 3B2/500s, two 
AT&T 3B2/400s, several PC labs, and an 
instructional laboratory. The campuses are 
fully networked. 

Applicants should have a Ph.D. degree 
and an outstanding record of research and 
teaching in Computer Science. Applications 
and nominations should be sent to the Chair¬ 
man of the Search Committee, Professor 
Theodor Tamir, Department of Electrical 
Engineering, Polytechnic University, 333 
Jay Street, Brooklyn, NY 11201. Polytech¬ 
nic is an Equal Opportunity Employer. 


CALIFORNIA STATE UNIVERSITY 
San Bernardino 

Position for Assistant or Associate Pro¬ 
fessor (tenure track) of Computer Science. 
Salary range $35,284-154,516 depending 
on qualifications and experience. Moving 
expenses. Available January, April or Sep¬ 
tember 1990. 

Duties include teaching, advising, curricu¬ 
lum development, research, and community 
interaction. Interest in digital logic, hard¬ 
ware, networking, and/or data bases is 
especially desirable. Teaching load equated 
to 12 hrs/wk of lecture and lab. Ph.D. in 
CSci is required. Facilities include CDC 
Cyber, Prime, IBM 4381 and Intel Hyper¬ 
cube computers, 286 and 386 PCs, micro¬ 
processors, terminals and several LANs. 

The University is located in one of the 
fastest growing service areas in the USA with 
a current student population of about 11000 
including 270 computer science majors. The 
area is noted for its warm climate and is 
within a 1-2 hr drive of mountain ski resorts, 
ocean beaches, and metropolitan Los 
Angeles. Housing costs average 20% lower 
than the LA area. Applicants should submit 
letter of application and vitae. Women and 
minorities are encouraged to apply. Position 
open until filled, but no later than June 1, 
1990. Send materials to: Dr. Peter Wetter- 
lind, Chair, Department of Computer Sci¬ 
ence, California State University, 5500 
University Parkway, San Bernardino, CA 
92407, PAAAAAR@CALSTATE.BITNET 

An Equal Opportunity/Affirmative Ac¬ 
tion, Section 504, Title IX Employer. 


DIRECTOR OF ACADEMIC 
COMPUTING/MEDIA SERVICES 

Beginning as soon as possible. MS in CS 
+ 3 yrs experience desirable. For position 
description write to James A. Halseth 
VP for Academic Affairs 
California Lutheran Univ. 

Thousand Oaks, CA 91360. 


LOUISIANA STATE UNIVERSITY 
Computer Faculty Position 

The Department of Electrical and Com¬ 
puter Engineering at LSU invites applica¬ 
tions for tenure-track and visiting faculty 
positions available August 1990 in all areas 
of computer engineering, including micro¬ 
processors, distributed processing systems 
and special purpose architectures. A Ph.D. 
or equivalent and potential for excellence in 
teaching and research are necessary. Rank is 
open. Salary is competitive and commen¬ 
surate with qualifications and experience. 
Release time and resources are provided in 
order to enhance the development of a 
quality research program. Opportunities for 
summer support are available. Send resume, 
names of three references, a statement of 
teaching and research interests, and verifica¬ 
tion of employment eligibility in compliance 
with the Immigration Reform and Control 
Act of 1986 to: Alan H. Marshak, Chair¬ 
man, Electrical and Computer Engineering, 
Louisiana State University, Baton Rouge, 
LA 70803-5901. LSU is an Equal Oppor¬ 
tunity Employer. 


UNIVERSITY OF WASHINGTON 

Department of Computer Science 
and Engineering 

Department of Statistics 

The University of Washington seeks can¬ 
didates for a possible tenure track position in 
scientific/statistical computing, to be held 
jointly in the Department of Computer Sci¬ 
ence and Engineering and in the Depart¬ 
ment of Statistics. Applicants should have a 
Ph.D. in Computer Science, Statistics, or a 
closely related field. We are specially in¬ 
terested in applicants with research interests 
in languages and systems for scientific com¬ 
puting, databases and information retrieval, 
or scientific visualization and graphics. 

The Department of Statistics is a leading 
center of research in statistical computing, 
meaning computing research relevant to the 
management, processing, exploration, sum¬ 
mary, and understanding of data used in 
decision making in science, engineering, 
public policy, and business. 

A moderate teaching load allows time for 
quality research and close involvement with 
students. We expect applicants to have a 
strong commitment to both research and 
teaching, and an outstanding record of 
research for their level. Any appointment 
should bring significant new research 
strength to both departments. Any applicant 
should be interested in collaborative research 
with faculty in both departments. 

Interested applicants should send a letter 
of application, a resume, and the names of 
four references to Computer Sciences/Sta- 
tistics joint Recruiting Committee, Depart¬ 
ment of Computer Science FR-35, Universi¬ 
ty of Washington, Seattle, Washington 
98195. 

AA/EOE 


UNIVERSITY OF 
WISCONSIN CENTERS 

We are seeking applicants for a full-time, 
tenure-track teaching position at UW Cen- 
ter-Waukesha and another possible teaching 
position at UW Center-Marathon. One may 
expect to teach twelve contact hours of lower 
division classes including programming and 
business applications. Master’s degree in 
computer science is required, Ph.D. prefer¬ 
red. Teaching experience at the college level 
is necessary and a knowledge of MIS is a 
plus. Salary is competitive. UW Center- 
Waukesha is one of thirteen freshman- 
sophomore campuses which comprise a unit 
of the University of Wisconsin. It enrolls ap¬ 
proximately 2300 students and is located a 
half-hour drive West of Milwaukee. UW 
Center-Marathon serves about 1100 students 
and is located in North-Central Wisconsin at 
Wausau, gateway to the recreational areas. 
To apply, send a letter indicating which posi¬ 
tion/s are of interest, a resume, three letters 
of recommendation, and transcripts to: John 
Heil, Chair CSEP; UW Center-FDL; 400 
Campus Drive; Fond du Lac, WI 54935. 
Phone (414) 929-3641 for more informa¬ 
tion. Closing date is February 28. The Uni¬ 
versity of Wisconsin Centers is an equal op¬ 
portunity, affirmative action employer and 
encourages women, members of minority 
groups and handicapped persons to apply. 
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UNIVERSITIES SPACE RESEARCH 
ASSOCIATION (USRA) 
Computer Scientist/Mathematician 

The Universities Space Research Associa¬ 
tion (USRA) is currently seeeking an experi¬ 
enced computer scientist to work on ad¬ 
vanced algorithm development in conjunc¬ 
tion with the Space Data and Computing 
Division at the Goddard Space Flight Cen¬ 
ter. The Division plays a vital role in the 
development, analysis, modelling, and utili¬ 
zation of data obtained by numerous sensor 
systems related to the space and earth 
science community research activities. The 
main NASA Space and Earth Sciences 
Computing Center (NSESCC) facilities in¬ 
clude a Massively Parallel Processor (MPP), 
a commercial replacement for the MPP, a 
Cyber 205 vector processor, and a planned 
Cray Y-MP. 

The selected applicant will survey the 
work being done in earth and space science 
at GFSC to identify problems and applica¬ 
tions that can be improved through advanced 
algorithm development. He or she will work 
on conversion, optimization, vectorization, 
or parallelization of existing NSESCC algo¬ 
rithms & applications to the new planned 
systems. New algorithms may need to be 
developed for the planned new architectures 
at the NSESCC. Particular generic computa¬ 
tional algorithms which could be investigated 
include PDE solvers, matrix operations and 
FFTs. The individual will be free to submit 
papers for publication and to present papers 
at scientific conferences on significant results. 

Applicants must have a Ph.D., or equiva¬ 
lent experience, in an appropriate field of 
computer science, mathematics, or physical 
science. Relevant experience in algorithm 
analysis and development is also essential. 
Experience and familiarity with the computa¬ 
tional issues related to space-based sensor 
systems is highly desirable. Salary will be 
competitive, commensurate with experi¬ 
ence. A relocation allowance is available if 
required. 

The Universities Space Research Associa¬ 
tion is a non-profit university consortium, 
chartered to foster cooperation between uni¬ 
versities and the U.S. Government toward 
the advancement of research and education 
in space science and technology. USRA is an 
equal opportunity employer. Applications 
received before April 1, 1990 will receive full 
consideration. Send curriculum vitae and 
contacts for reference to: 

Dr. Frank J. Kerr 

USRA Visiting Scientist Program 

Code 610.3 

NASA Goddard Space Flight Center 
Greenbelt, MD 20771 
(301) 286-5057 


TEXAS A&M UNIVERSITY 
Endowed Chair 
in Software Engineering and 
Parallel Computation Systems 

Texas A&M University invites nomination 
of qualified individuals for an endowed chan- 
in software engineering and parallel compu¬ 
tation systems, with specialization in any of 
the related areas. Candidates should have 


outstanding professional and personal qual¬ 
ifications, including national and interna¬ 
tional recognition for their contributions. 
Nominations of qualified individuals from 
both industrial and academic backgrounds 
are solicited. The successful candidate will be 
expected to provide leadership in both re¬ 
search and teaching. The academic rank 
will, of course, be Professor with tenure. 

Sophisticated and complex parallel soft¬ 
ware systems will be the driving forces for 
much of computer science and engineering 
during the next decade. Software system 
applications will range from scientific compu¬ 
tation, to business applications, engineering 
applications, to real-time embedded sys¬ 
tems. A broad range of problems must be 
addressed in these areas including software 
engineering research on software develop¬ 
ment methodologies, tools and environ¬ 
ments; parallel algorithms; scheduling for 
distributed and parallel real-time systems; 
languages for real-time and parallel systems; 
development of theoretic foundations for 
such systems, etc. The chair recipient will 
have a leadership role in this development at 
Texas A&M. 

Texas A&M is making a major commit¬ 
ment to establishing an outstanding program 
in Computer Science and Engineering. A 
substantial external contribution has enabled 
the creation of a heavily endowed chair in 
software engineering and parallel computa¬ 
tion systems area as part of this effort. The 
Department will move into a new building in 
January 1990. With the building the Depart¬ 
ment will receive an allocation of $1,500, 
000.00 for new equipment. In addition, the 
College is preparing to make substantial in¬ 
vestments in facilities to support leading edge 
research in areas involving advanced com¬ 
puter architectures. There is strong industry 
support for Department advances and am¬ 
ple opportunity for joint industry/university 
endeavors. The successful candidate can 
play a major role in the decisions to be made 
in these areas, and will have the opportunity 
to shape the direction of software engineer¬ 
ing and parallel computation systems re¬ 
search in the Department. 

Please send nominations to Professor 
Richard A. Volz, Head, Department of 
Computer Science, Texas A&M University, 
241 Zachry Engineering Center, College 
Station, Texas 77843. Initial screening will 
include applications received prior to April 1, 
1989. Minorities and women are particularly 
encouraged to apply. 


AUBURN UNIVERSITY 
Earle C. Williams Eminent Scholar 
Chair in Electrical Engineering 

Nominations and applications are invited 
for the Earle C. Williams Eminent Scholar 
Chair in Electrical Engineering. Candidates 
for this chair should have achieved national 
and international prominence in digital sys¬ 
tems and/or microelectronics. 

Applicants or nominees must have an 
earned doctorate, senior academic experi¬ 
ence, and a documented record of distinc¬ 
tion in university teaching and research. The 
successful candidate will be expected to pro¬ 
vide intellectual leadership in his/her area of 
expertise for the Department of Electrical 


Engineering as well as enrich the scholarly 
environment of Auburn University. 

Auburn University is located'in the city of 
Auburn in east-central Alabama. This land- 
grant university enrolls more than 21,000 
students, the largest on-campus enrollment 
in the state. The Department of Electrical 
Engineering, one of eight departments 
within the College of Engineering, offers 
Bachelor, Master, Master of Science and 
Ph.D. degrees in Electrical Engineering. The 
department has a current enrollment of 939 
undergraduate students and 100 graduate 
students. The 28 full-time faculty have an 
annual research expenditure of approxi¬ 
mately $2 million. 

The Search Committee will begin its re¬ 
view of applications on April 1, 1990. The 
position will be available on September 16, 
1990 or as soon thereafter as a candidate 
can be selected. Interested candidates 
should submit; (1) a detailed resume, (2) a 
letter indicating an interest in the chair, the 
candidates’s academic philosophy and a 
brief statement of accomplishments in teach¬ 
ing and research, and (3) names and ad¬ 
dresses of five references. Nominations 
should be submitted with the complete 
name, mailing address and telephone num¬ 
ber of the individual nominated. 

Applications and nominations should be 
sent to Professor J. David Irwin, Department 
of Electrical Engineering, Auburn University, 
Auburn, AL 36849-5201. Auburn University 
is an affirmative action/equal opportunity 
employer. Applications from minority and 
female candidates are encouraged. 


MISSISSIPPI STATE UNIVERSITY 
Head, Department of 
Computer Science 

Mississippi State University invites applica¬ 
tions and nominations for the position of 
head of the Department of Computer Sci¬ 
ence. A successful candidate must have (1) 
an earned doctorate in computer science or 
related field, and (2) faculty experience in a 
doctoral granting program. In addition, can¬ 
didates should have demonstrated leader¬ 
ship and a successful record of teaching, 
research, and grant procurement. The ap¬ 
pointment will be at the rank of professor 
with a highly competitive salary. The an¬ 
ticipated starting date is July 1, 1990. 

As one of the 100 largest research univer¬ 
sities (expenditures) in the country and the 
largest university in the state, MSU offers a 
broad range of undergraduate and graduate 
programs. The Department of Computer 
Science offers a CSAB-accredited under¬ 
graduate program and graduate study lead¬ 
ing to the MCS, MS and PhD degrees. In co¬ 
operation with electrical engineering, the 
department also offers programs of study 
leading to the BS and MS degrees in com¬ 
puter engineering. 

Screening of candidates will begin Febru¬ 
ary 15, 1990 and will continue until the posi¬ 
tion is filled. Nominations and applications 
with curriculum vita should be sent to: Dr. 
George S. Rent, Chairperson, Search Com¬ 
mittee for Head of Computer Science, Col¬ 
lege of Arts and Sciences, P.O. Box AS, 
Mississippi State, MS 39762. MSU is an equal 
opportunity affirmative action employer. 
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SOUTHERN COLLEGE 
OF TECHNOLOGY 
Computer Science Faculty Position 

The applied Computer Science Depart¬ 
ment of Southern College of Technology in 
Marietta, Georgia invites applications for a 
tenure-track fac'ulty position starting in the 
1990-91 school year. 

This position requires a master’s degree in 
computer science or a closely related disci¬ 
pline; candidates with the PhD in computer 
science are preferred. 

The candidate should have a minimum of 
three years of relevant industrial experience 
and/or teaching experience. We are espe¬ 
cially interested in applicants who have a 
strong desire to teach artificial intelligence 
courses, but the position requires teaching in 
other areas of computer science as well. 

The Applied Computer Science Depart¬ 
ment currently offers a Bachelor of Science 
degree in three major areas. There are eight 
full-time and six part-time faculty, with ap¬ 
proximately 400 majors. The department 
also teaches required service courses taken 
by all undergraduates. 

Southern College of Technology is a 
4-year senior college in the University Sys¬ 
tem of Georgia, with an enrollment of ap¬ 
proximately 4000. The school’s main mis¬ 
sion is one of teaching and not research. 
Southern Tech is located fifteen miles from 
downtown Atlanta in a dynamically growing 
suburb. Undergraduate degrees in technical 
disciplines and master’s programs in Techni¬ 
cal Communication and Technical Manage¬ 
ment are offered. 

Salary and faculty rank depending on ex¬ 
perience and qualifications. Send letter of 
application and resume to Prof. Fred Hart- 
field, ACS Department, Southern College of 
Technology, 1100 South Marietta Pkwy., 
Marietta, GA 30060-2896 by March 1, 
1990. Southern Tech is an Affirmative Ac¬ 
tion/Equal Opportunity employer. Applica¬ 
tions from minorities and women are partic¬ 
ularly encouraged. 


OHIO UNIVERSITY 
Computer Science Department 

Full-time, tenure track position as Assis¬ 
tant/Associate Professor to conduct re¬ 
search and to teach Computer Science 
graduate and undergraduate courses. Can¬ 
didates must have a Ph.D. in Computer Sci¬ 
ence or equivalent (at time of appointment) 
with promise of excellence in research and 
teaching. Applicants in the area of 
Database Theory will be given first consid¬ 
eration. 

Academic computing is supported by and 
IBM 4381, an HP3000, and several micro¬ 
computer labs. Departmental computing is 
supported by a VAX 780, VAX 750, several 
AT&T 3B2’s, and two microcomputer labs. 

Salary highly competitive (minima 
$40,000/$45,000). Application deadline: 
March 30, 1990. Search may be extended 
if suitable candidates are not found. Send 
vitae to and have three letters of reference 
sent to: Klaus E. Eldridge, Chairman, Com¬ 
puter Science Department, Morton Hall 
423, Athens, OH 45701. Ohio University 
is an Equal Opportunity/Affirmative Ac¬ 
tion Employer. Women and Minorities are 
encouraged to apply. 


OREGON STATE UNIVERSITY 

Department of Computer Science 

The Department of Computer Science 
anticipates new tenure-track positions for 
Assistant, Associate, and Full Professor¬ 
ships. Specialization in computer graphics or 
software engineering is desirable, but all 
qualified applicants will be considered. Ap¬ 
plicants should have completed or expect to 
complete all requirements for a Ph.D. in 
computer science or a closely related field 
and should have demonstrated research and 
teaching potential. Candidates for senior 
positions should have established research 
reputations. Review of applications will begin 
November 1, 1989, and will continue until 
the positions are filled. Please send vita, 
statement of research interests and plans, 
and three letters of reference to: Walter G. 
Rudd, Chairman, Department of Computer 
Science, Oregon State University, Corvallis, 
OR 97331. 

Oregon State University is an equal op¬ 
portunity affirmative action employer and 
complies with Section 504 of the Rehabilita¬ 
tion Act of 1973. OSU has a policy of being 
responsive to the needs of dual-career 
couples. 


WRIGHT STATE UNIVERSITY 

Department of Computer Science 
and Engineering 

Applicants are invited for tenure-track and 
visiting professors at all levels. Senior profes¬ 
sors are invited to apply for visiting and re¬ 
search positions. The successful candidate 
should have a PhD in computer science, 
computer engineering, or equivalent back¬ 
ground and have demonstrated forward 
looking and creative research. Further de¬ 
sired attributes include: capability to direct 
PhD candidates in computer science or com¬ 
puter engineering and the ability to acquire 
funds and/or direct research projects. All 
technical areas will be considered including: 
machine learning and neural networks, op¬ 
erating systems, programming languages 
and numerical methods. Rank and competi¬ 
tive salaries are determined by qualifications 
and experience. 

The university is located in a high technol¬ 
ogy environment among industrial/military 
research and development facilities including 
Wright-Patterson Air Force Base and NCR. 
Department strengths include a fully net¬ 
worked Unix environment of Sun worksta¬ 
tions, Cray access, graduate laboratories in 
AI, optical computing, neural networks, and 
robotics; established research programs; in¬ 
dustrial/military support; degree programs 
in both computer science and computer 
engineering, and a large graduate student 
population. 

Please submit a detailed resume including 
names of three references to: CSNET ad¬ 
dress: amcaulay@cs.wright.edu or Alastair 
D. McAulay, NCR Distinguished Professor 
and Chair, Department of Computer 
Science and Engineering, Wright State 
University, Dayton OH 45435. Reviewing 
for positions will begin February 15 and con¬ 
tinue monthly until positions are filled or until 
September 1, 1990. 

An equal opportunity/affirmative action 
employer. 


THE UNIVERSITY OF TENNESSEE 

Department of Computer Science 

Knoxville, Tennessee 37996-1301 

The Department of Computer Science in¬ 
vites applications for tenure-track positions at 
the rank of Professor beginning Spring 1990. 
A strong research record in the areas of com¬ 
puter graphics, networking, or operating sys¬ 
tems is sought but all major fields in computer 
science may be considered. Experience 
directing doctoral students is especially im¬ 
portant. Tenure-track positions for Associate 
and Assistant Professors are also open. Ap¬ 
plicants for Associate Professor should have 
a strong research record, preferably in the 
above-named areas; experience directing 
doctoral students is desirable. Applicants for 
Assistant Professor should have a strong in¬ 
terest in research, preferably in the above- 
named areas. Applicants for all positions 
should have a doctoral degree in computer 
science or a related area. 

Departmental SUN, IBM and DEC work¬ 
stations abound for students and faculty and 
are fully networked. Special systems support 
graphics and image analysis. The University 
operates an IBM 3090 and a large VAX 
cluster. CRAY, HYPERCUBE, SEQUENT 
and other machines are available via high 
speed link with Oak Ridge National 
Laboratory. 

You can respond to straight©utkvx.utk. 
edu. The mailing address is Department of 
Computer Science, 107 Ayres Hall, The 
University of Tennessee, Knoxville TN 
37996-1301. 

The University of Tennessee is an EEO/ 
AA/TITLEIX/SECTION 504 employer. 


CONCORDIA UNIVERSITY 

Centre for Pattern Recognition and 

Machine Intelligence (CENPARMI) 

CENPARMI is a new centre established in 
the Faculty of Engineering and Computer 
Science at Concordia University to foster 
close collaborations among active resear¬ 
chers in Pattern Recognition and Machine 
Intelligence and the industrial sector. Pre¬ 
sently 10 faculty members and 35 research 
staff and graduate students are associated 
with the centre. 

CENPARMI invites applications for three 
post-doctoral and research positions in op¬ 
tical character recognition and document 
understanding, machine learning applied to 
pattern recognition, and specification qnd 
implementation of expert systems starting 
Spring or Summer 1990. Candidates should 
have experience in one of the above areas. 
Send resume, reprints of publications, and 
the names of three or more references as 
soon as possible and before March 30, 1990 
to Dr. C.Y. Suen, Director, Centre for Pat¬ 
tern Recognition and Machine Intelligence, 
Concordia University, 1455 de Maison- 
neuve Boulevard West, Montreal, Quebec 
H3G 1M8, Canada. 

In accordance with Canadian Immigration 
requirements, this advertisement is directed 
to Canadian citizens and permanent resi¬ 
dents. However, foreign applicants are also 
encouraged to apply. 
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IEEE COMPUTER SOCIETY 
Membership / Subscription Application 



BENEFITS 



Computer 

Computer comes automatically 
with membership. Written, 
reviewed, and refereed by 
experts, it features survey and 
tutorial articles covering the 
entire computer field, and 
departments such as new 
products, new product reviews, 
standards, and a reader forum 
called "The Open Channel." 
(monthly). 


Technical Committees 

' Participate in one or more of our 33 technical 
committees — networks of professionals with common 
interests in specialty areas within computer hardware, 
software, and applications. 

Standards Working Groups 
Participate in the development of the more than 100 
standards projects currently sponsored by the society 
in such diverse areas as software engineering, local 
area networks, microprocessor buses, design automa¬ 
tion, programming languages, and standards 
definitions. 

Computer Society Press Books 

Receive discounts of up to 50% on over 600 titles 
covering a broad spectrum of computer science topics 
such as networking, communications, advanced 
systems, image processing, security, artificial 
intelligence, and design automation. Over 60 new titles 
are published annually. 

Conferences and Tutorials 
Choose from more than 100 conferences annually, 
ranging from large industry-oriented conferences 
replete with exhibits to small, highly interactive 
workshops. Members receive special low rates. 


_ . . , To join: see item 1,2, or 3. 

Schedule Of Fees To subscribe: see item 4. 

Membership dues and periodical subscriptions are annualized to, and expire on, 
December 31. Choose full- or half-year rate schedules depending on date of 
receipt by the Computer Society as indicated below. Half Year Full Vfear 
Mar 1-Aug 31 Sept 1-Feb 28 


I don’t belong to the IEEE and I want 
to join just the Computer Society 


□ $23.50 □ $47.00 


) I don’t belong to the IEEE and I want 
■ to join both the Computer Society and the IEEE* 

I reside in Region 1-6 (United States). □ $47.50 □ $95.00 

I reside in Region 7 (Canada). □ $43.50 □ $87.00 

I reside in Region 8 (Europe, Africa, orthe Middle East) □$43.00 □$86.00 
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I reside in Region 10 (Asia and Pacific). □$38.50 □ $77.00 

ie Computer Society may deduct $5 off the 


( I already belong to the IEEE and I want 
to join the Computer Society. 

IEEE Member Number_ 


□ $ 9.00 □ $18.00 


^ OPTIONAL PERIODICALS for new or current members 

IEEE Computer Graphics and Applications (3061) 6 □ $10.00 

IEEE Design and Test (3111) . 

IEEE Expert (3151) . 
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IEEE Software (3121) . 

Transactions on Computers (1161) 
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Transactions on Pattern Anaysis and 
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Total amount remitted with this application $ 
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U.S. currencies. U.S. checks must be drawn on a U.S. bank. 
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BOOK REVIEWS 


Editor: Guy Johnson, School of Computer Science, Rochester Institute of Technology, Rochester, NY 14623. 


The Illusion of Reality 

Howard L. Resnikoff (Springer-Verlag, New York, 1989, 339 pp., $44) 


The Illusion of Reality is a powerful 
and important book that clarifies the na¬ 
ture of information science and its foun¬ 
dations. The author carefully extracts, 
transforms, and communicates unifying 
principles from mathematics, biological 
systems, physics, electrical engineering, 
and computer science to provide a con¬ 
nective tissue for diverse topics. (The title 
was inspired by quotes from Tennessee 
Williams and John Archibald Wheeler.) 
Chapters cover the mathematics of infor¬ 
mation measurement, physical measure¬ 
ments and information, principles of in- 
formation-processing systems and signal 
detection, biological signal detection and 
information processing, and pattern 
structure and learning. 

Each chapter starts with an appropriate 
quote to stimulate the reader’s interest, 
and Chapters 2-6 each have an introduc¬ 
tory section stating the chapter’s purpose. 
Biographical sketches at the end of the 
book profile Boltzmann, Carnot, Fechner, 
Fourier, Grassmann, Heisenberg, 
Helmholtz, Maxwell, Szilard, Turing, 
von Neumann, Weber, and Wiener. There 
is also a 16-page reference section and an 
index; however, the chapters do not have 
question or exercise sections (a minor 
problem for instructional use). 

Chapter 1 sets the tone for the rest of the 
book by defining the science of informa¬ 
tion as that which concerns the structure 
of patterns and information transfer as 
well as systems capable of bearing infor¬ 
mation. Topics introduced here include 
knowledge representation (brain versus 
machine), learning, information capture 
(feature extraction), selective omission 
and heuristics, consistency and complete¬ 
ness of axiomatic systems, adaptive sys¬ 
tems, invariance issues, and hierarchical 
organization of information-processing 
structures. 

Chapter 2 deals primarily with identi¬ 
fying and measuring the information con¬ 
tent of numbers that derive from sensed/ 
observed magnitudes and mathematical 
processes. Chapter 3 then covers uncer¬ 


tainty, entropy, thermodynamics, con¬ 
servation issues, and special relativity, 
while Chapter 4 is concerned with system 
issues such as organization, hierarchy, 
topology, parallel processing, noise, and 
tools such as Shannon’s sampling theo¬ 
rem and Fourier analysis. 

Chapter 5 focuses on information sci¬ 
ence’s key principles: selective omission 
of information, organization of systems 
to maximize or minimize information, 
hierarchical organization of information 
processing systems, and group invariant 
functions. The chapter addresses such is¬ 
sues as pattern continuation and sequen¬ 
tial versus parallel signal processing. 
Human vision and image processing as 


Books in MIT Press’ logic program¬ 
ming series appear infrequently. This is 
only the sixth since the series began in 
1986. The series editor deserves our con¬ 
gratulations for the high standard main¬ 
tained to date. 

My interest in logic programming 
stems from involvement in an Esprit re¬ 
search project more than three years ago, 
when Peter Jackson’s earlier book, Intro¬ 
duction to Expert Systems (Addison- 
Wesley, 1986), provided an excellent in¬ 
troduction to the field. This new book de¬ 
scribes research in the United Kingdom 
supported by the Alvey Directorate, 
which was responsible for planning and 
administrating a joint academic-industry 
information technology program that 
could be described as the British govern¬ 
ment’s response to the Japanese Fifth- 
Generation Project. 

The book describes research based on 
two hypotheses: that logic is a suitable 
knowledge-representation language and 


well as visual illusions are also covered 
here, and the chapter includes a number 
of striking illustrations. Chapter 6 serves 
well as both a summary of the past and a 
taste of the future. Texture and textons 
are considered, and the chapter closes by 
examining the role of neurons and neural 
networks. The graphics here are excep¬ 
tional as well. 

In summary, this remarkable book 
presents a comprehensive view of infor¬ 
mation science and is appropriate as an 
advanced undergraduate or graduate- 
level introduction to the subject. 

Michael G. Murphy 

University of Houston 


that an explicit representation of the theo¬ 
rem prover’s control regime has many 
advantages. At the heart of the book is a 
description of the Socrates toolkit archi¬ 
tecture for building expert systems and a 
description of AI application systems 
that have been implemented in Socrates. 

The book shows the quality work that a 
industry-university team can achieve. It 
is sensibly arranged and accessible to 
anyone with some basic knowledge of 
logic and computer programming. The 
conclusions are clearly stated, the authors 
freely acknowledge the limitations of the 
Socrates framework, and they offer sug¬ 
gestions on where further work is needed. 

Overall the authors exhibit a refresh¬ 
ing lack of hype, an example I hope other 
authors (and their publishers) will fol¬ 
low. AI is too important to be abandoned 
to the charlatan. 

John Jenkins 

City University, London 


Logic-Based Knowledge Representation 

Peter Jackson, Han Reichgelt, and Frank van Harmelen, eds. (MIT Press, Cam¬ 
bridge, Mass., 1989, $35) 
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Error-Correcting Coding Theory 

May Young Rhee (McGraw-Hill, New York, 1989, 462 pp., $49.95) 


Errors can occur when data is transmit¬ 
ted over communication channels or 
recorded in storage media. This book ex¬ 
amines the analysis, design, and imple¬ 
mentation of encoders and decoders that 
estimate the desired results of data stor¬ 
age and transmission. This area, known 
as error-correcting coding, began in 1948 
with Clause Shannon’s paper, “A Mathe¬ 
matical Theory of Communication.” 
Rhee’s book introduces research in this 
field through the early 1980s, emphasiz¬ 
ing both theory and applications. Knowl¬ 
edge of error-correcting coding is in great 
demand, and the book would be a good re¬ 
source for computer engineers and com¬ 
puter scientists who are designing and 
constructing large digital systems. 

Since abstract algebra provides the 


support for error-correcting coding the¬ 
ory, the author’s introductory overview 
is followed by a chapter that gives the 
reader a minimal but somewhat rigorous 
explanation of the algebraic framework. 
The author limits his coverage to what he 
feels the reader needs to understand the 
succeeding chapters. 

The author classifies coding into coding 
for block codes and coding for convolu¬ 
tional codes. For block codes an informa¬ 
tion sequence is encoded into informa¬ 
tion blocks of a certain number of l’s and 
0’s. Binary convolutional codes can be 
generated by linear finite state machines 
connected to an m-stage shift register 
with some shift register stages connected 
to Modulo-2 adders. The author devotes 
six chapters to detailed discussion of 


block codes and three chapters to convo¬ 
lutional codes. 

The information in this book would be 
worthwhile to graduate students and 
practicing computer engineers and com¬ 
puter scientists. It is well organized and 
presented, although it requires hard study 
in many instances. Also, the bibliography 
is okay but not extensive. The book is full 
of examples, exercises, and algorithms 
for both the neophyte and the experi¬ 
enced practitioner, so it should serve rea¬ 
sonably well as the basis for a graduate 
course on error-correcting coding or as a 
reference work. The book fills the need 
for a survey on error-correcting coding. 

John W. Fendrich 

Bradley University 


Fundamentals of Database Systems 

Ramez Elmasri and Shamkant B. Navathe (Benjamin/Cummings, Redwood City, 


The database field is well estab¬ 
lished, and books in this area can be 
classified easily. An Introduction to 
Database Systems by C.J. Date (Ad- 
dison-Wesley, 1986) is acknowledged 
as the leading general computer- 
science textbook in this field, but Fun¬ 
damentals of Database Systems has a 
very good chance of dislodging it from 
the top of the heap. Elmasri and Navathe 
provide a broader perspective on the 
field than does Date. Their book is ex¬ 
tremely well organized and written, 
and it covers state-of-the-art topics as 
well as the proper historical material. 
The book would be accessible to under¬ 
graduates with a standard background 
in programming languages and basic 
file-organization techniques. 

As the authors suggest, this book 
could serve a one- or two-semester se¬ 
quence of database courses for junior- 
or senior-level students. In fact, a one- 
quarter or one-semester course could 
consist of just the material in Parts I and 
II. Topics are organized so that individ¬ 
ual instructors could cover topics in 
different orders or omit particular 
chapters. The book’s 23 chapters are 
organized into six parts plus four ap¬ 
pendixes, a comprehensive bibliog¬ 
raphy, and separate indexes of techni¬ 


cal terms and authors. 

This book could certainly be used as 
a comprehensive reference to the field, 
but its value is far greater as a textbook. 
With that in mind, it seems appropriate 
to concentrate on individual chapters 
and how certain topics are handled. 

The cornerstone of Part I is Chapter 
3, which introduces entity-relationship 
modeling. Prior to this, the reader has 
been introduced to basic concepts and 
terminology, the idea of data models, 
and the typical architecture of most 
database management systems. Chap¬ 
ter 1 also includes an excellent chronol¬ 
ogy of the major milestones in database 
development. In introducing entity- 
relationship modeling, the authors pre¬ 
sent all the basic concepts and illustrate 
a standard diagramming technique. 
There are examples and even some cov¬ 
erage of nonbinary relationships. The 
chapter also includes, as do all the 
chapters, a number of exercises that 
could be assigned as homework. The 
remainder of Part I deals with physical 
issues such as file organization op¬ 
tions, access methods, and indexes. 

The number of options presented is 
fairly large and up to date, as evidenced 
by coverage of dynamic hashing tech¬ 
niques and B-trees. 


Calif., 1989, 802 pp., $39.95) 

Part II is quite long, comprising 
seven chapters that focus on database 
models and languages. It also offers an 
interesting contrast to Date’s book. 

The relational data model and relational 
algebra are bundled into one chapter 
(Date devotes a chapter each to rela¬ 
tional structures, constraints, and data 
manipulation), followed by a chapter 
on Structured Query Language. While 
the general approach to presenting 
SQL is similar to Date’s, the authors 
also cover views, indexes, and embed¬ 
ded SQL in this one chapter. 

This pair of chapters is followed by 
another similarly organized pair: One 
chapter presents the basic concepts of 
relational calculus, and the second pre¬ 
sents concrete realizations through 
Quel and Query-by-Example. Follow¬ 
ing this are two chapters covering the 
hierarchical and network models. In 
each case, the reader gets a sense of the 
basic structural ideas, what constraints 
apply, and how to manipulate objects 
using systems modeled in these ways. 
The authors illustrate their points with 
languages based on DL/1 and typical 
network packages. Specific database 
commands are embedded in a Pascal¬ 
like host language that is easier to deal 
with than Date’s somewhat baroque 
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Knowledge Systems Design 

John K. Debenham (Prentice Hall, Englewood Cliffs, N.J., 1989, 302 pp, softcover, $38.95) 


Here is a handy, college-level book on 
designing expert and deductive database 
systems using first-order predicate logic 
programming. The book emphaizes AI 
business applications rather than scien¬ 
tific and technological applications, and 
it uses logic programming because of its 
central role in the Japanese Fifth-Genera¬ 
tion Project rather than because of pos¬ 
sible defects in Lisp or Ada. The author’s 
design methodology eases system soft¬ 
ware maintenance by using a “normal¬ 
ized model” of the specific applications. 

The book contains numerous illustra¬ 
tions and diagrams as well as several ex¬ 
amples and a case study. However, there 
are no student exercises to test the grasp 
of fundamentals. Thus, this book does not 
lend itself to rewarding independent 
study unless the reader has significant 


computer science background. Indeed, 
the author assumes the reader is familiar 
with such books as D.A. Waterman’s A 
Guide to Expert Systems (Addison- 
Wesley, 1986). 

The 10 chapters cover a broad range of 
interesting topics including fifth-genera¬ 
tion systems, logic as a programming lan¬ 
guage, logic as a database language, 
knowledge-system design problems, 
normal forms, and knowledge acquisi¬ 
tion. Further, there are useful discussions 
of knowledge analysis, knowledge engi¬ 
neering, knowledge-base implementa¬ 
tion, and system management and main¬ 
tenance. 

The author’s design analysis is deep 
enough to show, for example, that one 
particular problem of knowledge-base 
engineering is NP-complete. Further, 


there are several hints about capturing 
good knowledge-system design. As AI 
moves toward sapient systems, which 
display not only expert knowledge but 
also “compassionate wisdom,” I believe 
logic programming will still be appli¬ 
cable in the form of higher-order predi¬ 
cate logics. This book’s value would be 
enhanced by including discussions of 
knowledge-system security and techno¬ 
logical knowledge-system design (such 
as space station support using AI). 

This tutorial would be best used as sup¬ 
plementary reading by advanced under¬ 
graduates and computer science profes¬ 
sionals interested in the design of expert 
business systems. 

Albert A. Mullin 

US Army Strategic Defense Command 


pseudocode. The concluding chapter in 
this part compares the three major im¬ 
plementation models (relational, hier¬ 
archical, and network) and shows how 
to map the entity-relationship model 
into each of them. This is an excellent 
way to close the section. 

Parts III and IV focus on the main is¬ 
sues facing designers of logical and 
physical databases, respectively. Each 
of the four chapters in Part III contains 
conceptually difficult material, requir¬ 
ing time and concentration. One chap¬ 
ter introduces functional dependencies 
and normalization up through Boyce 
Codd normal form. The discussion 
moves from an intuitive presentation to 
a more rigorous one that includes infer¬ 
ence rules for functional dependencies 
and concepts such as minimal cover. 
The next chapter presents additional 
dependencies and normal forms. It also 
gives algorithms that preserve depen¬ 
dencies and produce nonloss decompo¬ 
sitions. Both chapters are well done, 
and the mathematical treatment of the 
topics is at the right level for most 
undergraduates. Part III closes with a 
look at some advanced modeling tech¬ 
niques. Features found in enhanced 
entity-relationship models are devel¬ 
oped, and other approaches, such as 
object-oriented and functional models, 
are briefly introduced. Finally, there is 
an overview of the database design 
process. 


In Part IV, the authors shift to practi¬ 
cal issues related to database system 
implementation. The section also in¬ 
cludes a relatively short chapter on data 
dictionaries that would benefit from 
some real examples taken from com¬ 
mercial products such as DB2 or Or¬ 
acle. Two other chapters stand out: one 
on query processing and optimization 
and a second on transactions, recovery, 
and concurrency control. First, the au¬ 
thors present the basic concept or iden¬ 
tify certain classic problems (for ex¬ 
ample, the “lost update” problem). 
Next, they provide traditional solutions 
and offer examples. Then, they give 
more complex or newer techniques. By 
the time the reader is finished, he or she 
has a full and rich appreciation of the 
problem and the possible solutions. For 
example, under optimization, the au¬ 
thors give traditional heuristic tech¬ 
niques as well as newer semantic query 
techniques. Locks are thoroughly dis¬ 
cussed with respect to transactions, and 
triggers are introduced in the discus¬ 
sion of integrity enforcement. 

Part V outlines current trends. In¬ 
cluded are a modest look at distributed 
database systems and the problems in¬ 
herent in using them, as well as a pot¬ 
pourri of new technologies and appli¬ 
cations. Here the reader will find trends 
in data models, database machines, 
spatial and temporal data management, 
and the connection between database 


techniques and artificial intelligence. 

Finally, Part VI presents interesting 
reviews of four commercial database 
products: DB2, IMS, IDMS (including 
its relational front end), and Vbase (an 
object-oriented package). In each case, 
the authors introduce the system, give 
basic architectural details, show data 
definition facilities and discuss the 
data dictionary (if appropriate), look at 
such internal features as data manipu¬ 
lation and storage, and assess the sys¬ 
tem. It’s sometimes difficult to tell 
which version of the product is pre¬ 
sented, but that’s a minor flaw in an 
otherwise useful section. 

Appendixes cover parameters stan¬ 
dard formulas for data transfer to and 
from disk storage, strengths and weak¬ 
nesses of SQL (modeled after an analy¬ 
sis made by Date), performance analy¬ 
ses of access methods, and a summary 
of relational algebra transformations. 

I commend the authors for crafting 
an excellent book. For the reader who’s 
serious about databases, I can’t think of 
another book that covers as much as 
this one. It provides historical balance, 
depth where necessary, and it clearly 
looks to the future. Database instruc¬ 
tors who traditonally have used Date’s 
textbooks (either Volume I or II) should 
seriously consider using this book. 

Henry A. Etlinger 

Rochester Institute of Technology 


February 1990 
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